|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI: new draftAm I missing something? As David states, it's the TCP layer that will handle SACK and recovering segments. The iSCSI layer will always have to buffer the full iSCSI message... To review: (in a single session scenario) TCP has buffering requirements of <window size> iSCSI has buffering requirements of <SCSI message size> The iSCSI layer must "buffer" data (somewhere) until a complete iSCSI message has arrived. If you are worried about "having to pile-up a lot of data in an adaptor or a separate memory area until you can figure where to put it" - isn't this what TCP's sliding window controls? When this begins to happen (because a packet was dropped), the receiving TCP can decrease it's window size advertisement. If you are using standard TCP implementations, and the iSCSI layer is strictly an application, it will NEVER receive out of order data. It will always know message demarkation from the iSCSI header length field. The use of the urgent pointer won't break this sort of implementation, but it won't necessarily augment it either. It seems to me the only time "framing markers" are useful (other than for facilitating protocol analyzers) is when you have an "accelerated" custom implementation of iSCSI/TCP where the iSCSI and TCP stack are intimately interconnected. In this case, framing markers of any kind allow the iSCSI layer to "sync up" framing when interim packets have been lost (somewhat independantly from the TCP mechanism). But what good will this do? Would an implementation deliver subsequent SCSI frames if you are missing a preceeding frame? And if it did, what will it do in the TCP layer to indicate those "out of order" bytes have already been delivered? This sort of implementation will maintain a fuzzy boundary between TCP and iSCSI. (just a statement, not a criticism) Go ahead, flame me if this has already been discussed, I admit I'm still catching up on my "reflector reading". Marjorie Krueger Networked Storage Architecture Hewlett-Packard Storage Organization tel: +1 916 785 2656 fax: +1 916 785 0391 email: marjorie_krueger@hp.com > -----Original Message----- > From: David Robinson [mailto:David.Robinson@EBay.Sun.COM] > Sent: Tuesday, November 07, 2000 2:50 PM > To: julian_satran@il.ibm.com > Cc: Raghavendra Rao; ips@ece.cmu.edu > Subject: Re: iSCSI: new draft > > > Are we again presuming that you can do anything to a TCP stream > out of order? If you miss a segment there is not much you > can do with the segments that may follow out of order. Although > you can buffer them, you might as well throw them away as they > WILL be resent. So even if you know the next message boundary > it gives you NO useful information until the entire > contents of the message arrives. The easy way to minimize > tempory storage is to just drop it if you are memory > constrained. > > -David > > julian_satran@il.ibm.com wrote: > > > > JP, > > > > No. If a packet arrives very late and others precede it, or > a packet is > > lost and recovered with SACK later > > you end up having to pile-up a lot of data in an adaptor or > a separate > > memory area until you can figure where to put it. The amount can be > > minimized if you can rapidly figure out where the next boundary is. > > Obviously you do not really hand the data to the user until > you have it all > > but you gain by having a place to store it sooner and > minimize the amount > > you have to keep in "temporary storage". > > > > Julo > > > > Raghavendra Rao <jpr@divyaroot.India.Sun.COM> on 08/11/2000 03:23:50 > > > > Please respond to Raghavendra Rao <jpr@divyaroot.India.Sun.COM> > > > > To: Julian Satran/Haifa/IBM@IBMIL > > cc: > > Subject: iSCSI: new draft > > > > Julian > > > > I've trouble in interpreting this in the new draft > > > > > Unfortunately, when relying solely on the "message length in the > > > iSCSI message" scheme to delineate iSCSI messages, a missing TCP > > > segment that contains an iSCSI message header (with the message > > > length) makes it impossible to find message boundaries > in subsequent > > > TCP segments. The missing TCP segment must be received before any > > > following segments can be processed. > > > > This suggests that TCP might deliver a stream with a > missing segment ! > > TCP will not deliver to session layer until the missing > segment arrives > > to satisfy the streaming protocol it defines. > > > > Have I misread something ? > > > > Thanks > > > > -JP >
Home Last updated: Tue Sep 04 01:06:30 2001 6315 messages in chronological order |