[e2e] A simple scenario. (Basically the reason for the sliding window thread ; -))
detlef.bosau at web.de
Fri Jan 5 06:13:56 PST 2007
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.
> Here is a more practical example -
> 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.
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
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
More information about the end2end-interest