Re: iSCSI: need for new data SNACK code?

["Mallikarjun C." <cbm@rose.hp.com>]

> However,
> your argument applies to both the previous discussion, and also seems to
> fall in David's favor, because the necessary state would need to be saved
> anyway (for any retransmission to happen).

Remember, I didn't argue that "necessary state" doesn't have to be saved -
that would be too brave on my part to do that.....   My metadata explosion 
comment was based on David's description that seemed to imply a tuple table.

> I guess what I was confused about is how this argues against having another
> opcode for the SNACK and against the target being the one catching the error
> condition.

Though not sure about what you mean by " target being the one catching the error
condition" (there's no error in redeclaration of max PDU size, except for the lost data 
itself - and the onus is on the initiator to "catch" that)....

This doesn't argue either way (and a needless subroutine call), I was pointing this
out when a comparable scheme on the initiator side was argued as flawed.
My point was and is that I see only implementation errors that can make the 
one-code scheme untenable, not any protocol issues.  Ironically, the same applies to 
the two-code scheme as well.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668 
Roseville CA 95747
cbm@rose.hp.com


----- Original Message ----- 
From: "Randy Jennings" <randyj@data-transit.com>
To: "Mallikarjun C." <cbm@rose.hp.com>; <Black_David@emc.com>
Cc: <ips@ece.cmu.edu>
Sent: Monday, July 15, 2002 2:26 PM
Subject: RE: iSCSI: need for new data SNACK code?


> Fair enough.  That is actually what I meant about being able to recalculate
> it somehow; although, I did not have it developed quite so neatly.  However,
> your argument applies to both the previous discussion, and also seems to
> fall in David's favor, because the necessary state would need to be saved
> anyway (for any retransmission to happen).
> 
> I guess what I was confused about is how this argues against having another
> opcode for the SNACK and against the target being the one catching the error
> condition.
> 
> Sincerely,
> Randy Jennings
> Data Transit
> 
> > -----Original Message-----
> > I believe one doesn't need to maintain exhaustive DataSN-to-PDU_size
> tuples
> > for all PDUs for all active tasks as David's revised description implied.
> IOW,
> > what I am suggesting is that a target can translate a DataSN to a buffer
> offset
> > (even with PDU size changes) with *much* less metadata, *if* it always
> sends
> > MaxRecvDataSegmentLegth sized data-in PDUs except possibly for the last
> PDU.
> > Any retransmission request would have to take the aforementioned
> size_changed_from
> > and PDU_size_history arrays into consideration, and calculate the
> > buffer offset accordingly.
> >
> > > > > The flag per task is not needed - I'd expect the Target to look
> > > > > at the Data PDUs it would have to resend, check them against the max
> > > > > Data PDU size for this connection and fail the regular SNACK if any
> > > > > PDU is too large
> > > >
> > > > I am afraid there's no free lunch here.  In this description, you're
> now
> > > > expecting targets to maintain the PDU size of every PDU that it
> shipped
> > > > for each of the tasks, which causes a metadata explosion.  This was
> discussed
> > > > by Eddy Quicksall and myself in an earlier thread - "changing
> MaxPDUDataLength".
> > >
> > > However, I do not remember what was said about knowing the length of the
> > > PDU.  From this isolated discussion, though, it seems like you would at
> > > least be able to recalculate the length of the PDU at all times
> > > or you could never send it again.  (Unless you redid all the steps that
> got
> > > to that point in the first place, and I do not think that is possible
> based
> > > off a PDU id
> > > number...)
> 
>