RE: Status summary on multiple connections

["Y P Cheng" <ycheng@advansys.com>]

> > I really do NOT see how one can allow a TCP to deliver out of order
> > though, oh
> > I know technically how to do it, but it is a fundamental violation
> > of what TCP is supposed to be delivering.... i.e. the bytes being
> > transfered from 0 to N...
>
> The scenario which everyone seems to be worried about is that
> packets are delivered in order, but the ACK for one of them is
> lost going back. Everything gets delivered to iSCSI, then the
> non-ACKed packet is delivered again.
>
> Does this really happen in today's stacks?
>
> It seems like the TCP stack would see it as a duplicate that
> has already been delivered to the upper layer and drop it.
> TCP does have sequence numbers and knows this. The only way
> I could imagine this happening is if there was sufficient
> data to wrap the TCP sequence space.

Randall and Mark:

Both of you forget about the case when multiple PDUs are inflight, say N,
N+1, and N+2, and one of them has CRC error, say N+1.  The receiver throws
away N+1 because the bad CRC.  N+2 is received long before N+1 is
retransmitted after a timeout by the sender.  Of course, a sequence number
inside the PDU will ensure sequentially.  However, as I stated in another
posting, all software realize such problem and will not count on sequential
delivery by a transport.

Y.P.