[e2e] AIMD synchronization Re: Reacting to corruption based loss
craig at aland.bbn.com
Wed Jun 29 18:24:01 PDT 2005
In message <200506300013.j5U0DWQn027542 at codex.cis.upenn.edu>, mbgreen at dsl.cis.u
> Tue, 28 Jun 2005 21:34:29 +0200
> Detlef Bosau <detlef.bosau at web.de>
> For the traditional AIMD scheme, it´s quite easy to see that AIMD
> sequences starting from different initial vaules will end up in the
> same sawtooth as long as alpha and beta are equally chosen for all
> competing flows.
>[Digression not directly relevant to your main argument:]
>I don't think this is "easy to see" if the RTTs of the competing flows
>are different --- I don't even think it is necessarily true that they
>end up in the same sawtooth. In simulations it is easy to have many
>flows with exactly the same RTT. In the real world this is less
It has been a long time since we've discussed synchronization of clock
type issues so I'm trying to reconstruct the issues here from memory.
As I recall there are two important factors here:
* congestion loss occurs when a queue's capacity is exceeded -- such
that several datagrams arriving in quick succession will mostly
suffer loss (a few will be lucky enough to arrive when a spot
in the queue has just opened).
Assuming these datagrams are from different TCPs -- this is a
synchronizing event. At the moment of loss, all of them effectively
enter congestion recovery -- albeit it with different timings
related to their RTTs and RTOs.
* if you view transmission times on a link (or spots in a queue)
as "success" events -- there's reason to believe that senders over
time sychronize their sending rate with successful events in
routers in the path (e.g., if you send a packet through successfully
you get an ack, which causes you to send a new packet at a time
when success is likely). There's a note from Van c. 1987 on
this subject that I think I still have and will forward if I
can find it.
More information about the end2end-interest