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

[Detlef Bosau]

Joe Touch wrote:
>   
>> The basic question is whether the use of a splitter may shorten the RTT
>> seen by the sender to that degree, that the appropriate rate cannot be
>> achieved by a sliding window protocol even if CWND were set to 1 MSS,
>> the sender must hence be stalled from time to time to have the rate slow
>> enough.
>>     
>
> The window doesn't by itself determine rate; it's ACK clocking that
> does. 

I´m totally with you.

In the scenario above, the splitter ack´s packets "to fast", when it 
does dumb spoofing.
In other words: Without splitting, the serialization delay of each link 
ensures that the sender is paced correctly via ACK clocking.
When a splitter is used, the ACK pacing mechanism can be undermined.
> In high BW*delay product nets, the same stalling happens - you
> send data, get an ACK, send more, get ACKs of that, etc - and the data
> keeps bunching up at the source.
>
> I.e., ACK clocking works only when the data-ACK look experiences a
> bottleneck. When it doesn't, things bunch up, and TCP doesn't 'match
> rates' at all.
>   

This was a little bit too fast for me....

Shouldn´t the ACKs be clocked by the TCP data packets, at least in 
symmetric paths? Thus, the ACK clocking should reflect the TCP rate 
which is achieved downstream?


> FWIW, the same thing happens when the receiver application doesn't drain
> the incoming data fast enough. The receive buffers fill up, and the
> sender is stalled. The same thing is happening here.
>
>   

Yes, absolutely. When a splitter is in use, the sending socket (directed 
to the final receiver) doesn´t drain its incomming data fast enogh.

It´s an interesting question whether data of short term flows can be 
buffered entirely at the splitter and then sent to the receiver with a 
rate the link can handle.
It´s interesting what handles to the final CLOSE ACK here which is 
typically not spoofed in splitters to ensure poper ACK semantics.

> Splitters are bad for other reasons, but as you said, let's ignore them
> for this discussion..
>
>   

I just see that they are in use. And so I think one should weigh up the 
pro´s and con´s here.
In the particular case of wide area mobile networks, I personally think 
splitters can be helpful because of the extremely irregular delivery 
times of datagrams.
I had great difficulties to see a reason for this and found Thierry 
Kleins paper !Improved TCP Performance in Wireless IP Networks through 
Enhanced Opportunistic Scheduling Algorithms" (Globecom 2004) extremely 
interesting.

Perhaps, the scheduling caused variations in packet delivery times are 
the most distinguishing mark for mobile wide area networks compared to 
other network technologies. (I would be glad to get comments on this claim!)

> It seems like the dominant effect is exactly what you expect - the
> endpoint (the splitter, really) isn't experiencing the bottleneck, but
> it's "application" (the receiver on the modem) is too slow. So you get
> bursty 'scheduling' of the sender based on availability of buffers at
> the (IMO, real, or at least effective) receiver.
>   

It´s just interesting to see, whether this is important / relevant / 
annoying.

Detlef