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

[Detlef Bosau]

Joe Touch wrote:
> PS - this could also happen within a single CWND, e.g., if the network
> path temporarily shifts around the TCP-splitter. It doesn't require an
> entire window wrap to occur.
>
> Joe
>
>   

Two remarks.

First.

The only scenrios where I see a justification / necessity for doing 
splitting or spoofing are scenarios where the TCP flow must pass the 
split box / spoofing box / PEP anyway. These are scenarios without path 
redundancy or path transparency. Hence, in these scenarios the path 
cannot temporarily shift around the splitter because no alternative path 
exist. If we want redundancy in those scenarios, we have to consider hot 
stand by nodes for splitters which keep flow states and any other data 
which is "hard" and cannot be recovered synchronously with the backed up 
system.

To be not misunderstood: I don´t want to make restrictions for the 
benefit of a splitter. I think in scenarios where an alternative path to 
a splitter exist, a splitter must not be used. In my opinion splitters 
are to be used with maximum care and only in exceptional cases where any 
known alternative is worse than a splitter.

Second.

To my understanding we can avoid wrap around problems by having the 
receiver window sufficiently small. And of course, a splitter does flow 
control by itself. I´m not convinced that it is necessary to have 4 
GByte of unacknowledged data in the fly in all networks. And _if_ we 
need windows of this size we can reconsider the length of our sequence 
numbers.  But at least for terrestrial networks 4 GByte of data in 
transit seems extremely large to me.

WRT mobile networks: I´m still looking for material about delivery times 
and their distributions. It´s absolutely not necessary to have accurate 
quantitative data here. But it would be helpful to know wether we have 
to cope with delay spikes of up to 1 second, up to 10 seconds or up to 
10 minutes and whether these happen once a minute, once a day or once a 
year. When we encounter maximum delay spikes of 1 second not more than 
once a decade, the best idea is to simply ignore these. If a (wireless) 
link offers 1 Gbps throghput and is blocked each other minute, the 
situation might be somewhat different.

Particularly, and perhaps Anil could help me there, I want to get an 
idea what is already done by NOs and where research is necessary. As I 
said before, I presume that there happen quite a lot of things which are 
not publicly documented. This can lead first to duplicate research. And 
second this can lead to "strange" problems where protocols and 
applications do not work for unkown reasons, and the real problem is 
that there is some strange middlebox in use which does one of these neat 
"company confidential" or "non disclosure" algorithms. Obscure 
middleboxes can render our whole work completely worthless because they 
can cause problems no one can solve.

Particularly, I eventually want to understand the problems TCP and other 
protocols encounter on mobile links - and afterwards I can take a 
position how these can be solved. As I said before, much of the 
literature in this context appears quite obscure to me. It simply makes 
no sense to e.g. talk about a splitter and its benefits in a mobile 
network when it is yet unclear whether a splitter is even necessary.

Detlef
> Agarwal, Anil wrote:
>   
>> Joe Touch wrote -
>>     
>>>> Well, it´s just how I understand the semantics of a "CLOSE ACK". When a
>>>> receiver issues a CLOSE ACK, we know that all data has reached the
>>>> receiving socket.
>>>>         
>>> We should know that. But when we have intermidiates spoofing ACKs, all
>>> we know is that the two endpoints agree that they have closed. The data
>>> itself is not known.
>>>       
>>> Case in point - if the intermediary ACKs data and continues to buffer
>>> it, and the window wraps, and then the intermediary goes down, the
>>> endpoints think the data reached the buffer correctly but it really
>>>       
>> did not.
>>
>> 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?
>>  
>> Cheers,
>> Anil
>> ------------------
>> Anil Agarwal
>> ViaSat Inc.
>>  
>>  
>>  
>>  
>>     
>
>