Re: [tmrg] [Tmrg] Is it possible that IW doesn't effect other traffic

[Bob Briscoe <[e-mail]>]

Matt,

Going back >2months (my mulling-over time constant ;)

At 22:55:58 -0400 22/08/2010 Matt Mathis wrote:
>I suspect that our inability to detect the intuitively expected
>result, that IW10 hurts IW3, may actually be a symptom of a deeper
>theoretical result that it really doesn't matter, because the system
>is memoryless. ?

[snipped the rest]

Surely the *queue* is memoryless but the *system* is not. In the 
classic design of TCP/IP, the congestion control's memory is all in 
the end-systems.

So when a queue drains, the queue forgets everything. But TCP hosts 
hold on to the memory of what their congestion windows were before 
the queue drained as they gradually probe the capacity again.

In fact, hosts remember their congestion windows and evolve them over 
long periods always depending on all the losses they saw previously 
(at least since the last idle period) to gauge what the available 
capacity probably is now. And over longer time periods they hold on 
to ssthresh too.

For proof, if you look at the critical path analysis of a session 
transaction (e.g. [Barford00]), a loss early on in a flow can "ruin 
your whole day" (so to speak), having far greater effect on session 
completion time than a loss later in the session. If the *system* 
were memoryless, this just wouldn't be able to happen.

True, if all the hits from one IW=10 spike impact just one flow (*if* 
it's a typical TCP), it will forget this after 1RTT and treat it like 
one loss. But, if a number of losses impact a number of flows, the 
memory of the difference between  IW=10 & IW=3 will last longer. 
According to Appendix B of [Padlesny06], it takes about 7 
increase-decrease cycles for TCP's AIMD to reach 98% fairness index 
(their own, not Jain's) after being upset from equality by a loss.

Let's not forget too that competing flows might not be TCP. Adaptive 
media (e.g. over RTP/RTCP) can have a long memory. RTCP counts losses 
irrespective of whether they occur within 1RTT or not, and can use 
this count to adapt its rate in future. In addition, inelastic 
congestion controls tend to be conservative, being slow to increase 
after a decrease because user experience is generally better with a 
stable low rate than a fluctuating medium rate.

A different sort of memory in the end-system: A VoIP flow can cover 
up loss of a small number of packets in a row by smudging the audio 
over the gap using its memory of the recent audio. But a spike of 10 
large packets might cause an AQM queue to knock out more than 10 
small (VoIP) packets. That would be harder to cover up, and continual 
IW=10 spikes could disrupt audio considerably.

Nothing here is really evidence for or against IW=10, and I'm open to 
be convinced that IW=10 makes more sense than IW=3. I just don't want 
to see this superficially convincing memorylessness argument take 
hold if it's bogus.

[Barford00] Barford, P. & Crovella, M., "Critical Path Analysis of 
TCP Transactions," Proc. ACM SIGCOMM'00, Computer Communication 
Review 30(4):127--138 (October 2000)
<<http://doi.acm.org/10.1145/347057.347416>http://doi.acm.org/10.1145/347057.347416>

[Podlesny06] Multimodal Congestion Control for Low Stable-State Queuing
Podlesny, Maxim; Gorinsky, Sergey
Washington Uni CS Dept Tech Report WUCSE-2006-41
<http://www.arl.wustl.edu/~gorinsky/pdf/WUCSE-TR-2006-41.pdf>


Bob


________________________________________________________________
Bob Briscoe,                                BT Innovate & Design