Re: iSCSI: new draft

[ronald lee <ronald.c.lee@sun.com>]

I don't really see the need to handle out of order segments
any differently than what it is today.
We can use multiple TCP connections with each given enough
memory to allow for the ACK to come back before shipping the
data to ULP.  If you lose a packet or receive a segment out of
order, it will just slow you down for an instant.  There is
no need to drop packets.  Other TCP connections can be used
to send task management requests which are urgent messages
and these connections does not require very much memory.
The faster you want to go the more memory you need.  No matter
how many connections you have on an adapter you will go at 
the rate of the physical interface whether it be 1GB or 10GB
so the maximum amount of memory can be calculated for all
connections to allow for high speed transfers.  Fast retransmit
in the order of micro seconds will really be desired to reduce
the length of the glitch in the event of a packet loss.

I believe that networks will become more reliable as we continue
to develop new technologies.  Definitely LANs can be made to
become more reliable and so all this effort to increase throughput
by putting in special algorithms might not be necessary.

Also, people wanting fast WAN connections can lease private lines
that can just about guarantee that they don't lose packets.  As
a home user, I personally wouldn't care too much if I lose a
packet here and there as long as my I/Os succeed to the storage
service provider.



	- Ron




David Robinson wrote:
> 
> Actually with SACK (RFC2018) all MAY be retransmitted depending
> on how the timers play out regardless of if the segments were
> 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.
> 
>         -David
> 
> Matt Wakeley wrote:
> >
> > 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