RE: iSCSI: new draft

[julian_satran@il.ibm.com]

Marjorie,

You are correct about a "tightly coupled" implementation being able to
better use out of order delivery but even plain vanilla TCP adapters can
benefit. You have to distinguish delivery (i.e., a user observable
end-of-operation) and "placement" (i.e. placing data in memory at their
final destination).  For specialized machines placement is not necessarily
a difficult operation as data can be placed anywhere and labeled later
(although even this is tricky) but client machines (initiators) do have
either to keep data in temporary buffers and
copy later or discard any data for which they miss the context (an iSCSI
header). Finding fast the next header might help minimize the amount of
data one drops or has to copy.

Julo


"KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com> on
08/11/2000 03:55:28

Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)"
      <marjorie_krueger@hp.com>

To:   "'David Robinson'" <David.Robinson@EBay.Sun.COM>, Julian
      Satran/Haifa/IBM@IBMIL
cc:   ips@ece.cmu.edu
Subject:  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
>