Re: iSCSI: new draft

[Raghavendra Rao <jp.raghavendra@india.sun.com>]

> put into the SACK. It is up to the client to determine what will
> actually happen, designing the server to depend on any of the optional
> SACK behaviors of the client is not very wise.
> 

I agree with David, Is the goal of the current draft to build mandatory
features in iSCSI to work with a peek-poke or datagram like TCP to be
built in hardware ? Or should it just work with TCP of today ?

I think a clarification to this effect is needed.

-JP

====== 

> > 
> > They will *not all* be retransmitted if SACK (rfc2018) and fast retransmit
> > (rfc2581) is implemented.
> > 
> > -Matt
> > 
> > David Robinson wrote:
> > 
> > > 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