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

[Detlef Bosau]

Agarwal, Anil wrote:
> Detlef 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.
>
> Yes
>

Great :-)

> Here is a more practical example -
>
> Sender
> -------------------------TCP-Splitter---------------------Receiver
>     100 Mbps, 10 us (LAN)      1 Mbps, 300 ms (geo-satellite)
> A cwnd of 1 segment of 1500 bytes will achieve roughly
> 1500 * 8 / (20 + 120) Mbps
> i.e., 85 Mbps, on the LAN segment,
> which is much higher than the satellite link rate.
>

The very interesting thing is that this behaviour is not restricted to a 
typical dialin modem bandwidth.
And the RTT from sender to splitter can even be in a range of some ms 
and we will still have the same behaviour.
> > So, what should the splitter do?
> > 1. stall the sender periodically using zero windo packets?
> > 2. don´t care, doesn´t matter?
> > 3. ??
>
> Since, the network can support a maximum of 1 Mbps,
> on average, the sender should send 1 segment every
> 1500 * 8 / 1000000 seconds
> i.e, every 12 ms.
>  
Yes.

Question: How is this achieved using actual splitters?

> So, stalling the sender using zero window Ack packets is an
> appropriate solution, which does not require any changes to the
> sender TCP stack. The cwnd value may be 1 segment or larger,
> it does not matter.

I wonder if splitters actually stall.

I personally think, stalling is an extremely bad solution as a stalled 
sender must wake up somehow or must be woken up somehow.
It is woken up by window updates, which unfortunately are sent 
unreliably as they typically do not carry any data bytes.
If it is not woken up, it wakes up by itself after some timeout and 
sends probing packets.

In my own simulations I did not yet implement window updates and do only 
zero window probing where I use the actual retransmission timeout for 
zero window probing as well.

The throughput decrease is, kindly spoken, disastrous. Depending on the 
parameters I choose, the flow actually uses only 25 % or less of the 
available bandwidth.

I have yet to add window updates. The problem with window updates 
however is to model the loss of window updates. This is a typical "paper 
tuning parameter (abbrev.: PTP)" If you choose this rate to low the 
paper will be rejected because it´s not relevant. If you choose it to 
high, no one believes your results (however, no one will call you a 
liar, it will be written more political correct) and somewhere in the 
middle you will find something between "weak accept" and "weak reject" :-)

O.k., but let´s wait for the "strong reject" comments now. I´m eager to 
know what the rest of the world is tinking about this problem.

In addition, I would appreciate any hint to actual papers on zero window 
probing.  (Of course there is a way to do it without zero window probing 
but I would like to see whether this is really needed or whether it´s 
irrelevant.)


Detlef