[e2e] AIMD synchronization Re: Reacting to corruption based loss

[Craig Partridge]

In message <200506300013.j5U0DWQn027542 at codex.cis.upenn.edu>, mbgreen at dsl.cis.u
penn.edu writes:

>   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
>common.

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.

Craig