[e2e] A simple scenario. (Basically the reason for the sliding window thread ; -))

[Agarwal, Anil]

Joe Touch wrote -
>> Are you describing a scenario where a TCP-Splitter buffers up 2^32 bytes
>> of sender
>> data without delivering any to the receive end-point, then goes down, and
>> the end-points continue the connection using the wrapped
>> sequence number, which in this case match up just right, so that the
>> intervening
>> 2^32 bytes disappear down a black hole, without the sender or receive
>> being any wiser?
>>
> Yes. The system can wrap without things matching up _exactly_, depending
> on how big the CWND is, though, so this isn't as absurdly specific as it
> appears at first glance.

I think, this scenario will occur if 
  the TCP-splitters buffer x bytes of undelivered data,
  the sender cwnd is y,
  x < 2^32 and x+y >= 2^32,
  the splitters go down and 
  packets flow between the sender and receiver over an alternate path.
 
In this case, the receiver rcv.nxt value is within the 
sender [snd.nxt , snd.nxt + cwnd) range and hence 
the receiver will acknowledge sequence number rcv.nxt and 
accept data beyond it; 
the sender will gladly accept the acknowledgement and 
continue sending data.
 
Now, we know 
  y < 2^30
a constraint required and imposed by TCP (rfc 1323).
 
We can claim that a (good) TCP splitter ensures that
  x < 2^31
 
Detlef - this is not as easy as it might first appear, especially
since data can get buffered at the sending or 
receiving TCP-splitter in a two-splitter case,
but it can be (is) done.
 
Hence, x + y < 2^32 and the above scenario will not occur.
 
The above also requires that TCP-splitters use
the same ISS (Inital Sequence Number) with the receiver
as the one used by the sender. 
A good TCP-splitter should (does).
 
Anil
-----------
Anil Agarwal
ViaSat Inc.
 
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20070113/e143068c/attachment.html