Re: Status summary on multiple connections

["Randall R. Stewart" <randall@stewart.chicago.il.us>]

Lyndon:

Comments below.. sorry in the delay.. I got a
bit behind being away from email for this group
is a bad thing :-) It takes a while to catch up :0




Lyndon Ong wrote:
> 
> At 08:05 AM 10/2/2000 -0700, Y P Cheng wrote:
> >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.
> 
> This confuses me.  Why would the application ever see the N+2 PDU, wouldn't
> it be queued by TCP until N+1 is delivered correctly?  It shouldn't matter
> if N+2 was delivered first or if it contains a sequence number at the
> higher layer, the higher layer would not get N+2 before N+1.
> 
> TCP would presumably not be aware of the boundaries between messages at the
> higher layer, but deliver what it sees as a stream of bits.
> 
> Cheers,
> 
> L. Ong
> 
> 
The above as I see it is exactly correct. In YP's example the upper
layer
above TCP will NEVER see N+2 if N+1 is not ready to be delivered. This
is the "head of line" issue that we needed to get around in sigtran.
N+2 will be held by TCP until N+1 is retransmitted via either
fast-retransmit
or timeout. Once N+1 arrives presto.. both will be presented in the
proper order to the upper layer...

And as far as message boundaries... there is NO such think in TCP.. it
is just a stream of bytes...


R

-- 
Randall R. Stewart
randall@stewart.chicago.il.us or rrs@cisco.com
815-342-5222 (cell) 815-477-2127 (work)