SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    RE: iSCSI: new draft



    Am 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