[Iccrg] Proposal for ICCRG operations

[Nandita Dukkipati]

Here's my take on the questions put forth by Keshav. For now I will  
limit my answers to elastic traffic.

>  A. What is the commonly agreed definition for congestion. (I will  
> post
> my suggestion later today). If we do not agree on a definition,  
> then indices
> are meaningless.

* A network-centric definition of congestion: Congestion is anything  
that deviates significantly from an efficient and fair usage of the  
network resources --- mostly network bandwidth and buffers.
* User-centric definition: From an user's view point what really  
matters is how quickly does my flow finish, so congestion is long  
flow-completion times. Often, it isn't the per-packet latency that  
users care about, but just how fast the entire flow completes.

>     B. What's wrong with TCP's congestion control scheme. Does  
> someone have
> a concise summary that they can post here? I am sure this will be a
> cut-and-paste job for someone who has written a paper on congestion  
> control
> recently :-)

Here's one list:

  1. Unsustainable large equilibrium window sizes under high  
bandwidth-delay product environments; requires an unrealistically low  
loss probability.
  2. Low throughput under lossy environments because of using loss as  
an indication of congestion.
  3. Slow additive increase: Takes a long time for flow to catch up  
with spare capacity and results in unnecessary long flow-completion  
times.
  4. Inefficient Slow-start: Even when the flow is capable of  
completing within a round-trip time, slow-start makes flows last  
multiple round-trip times just to find their fair share rate. Often  
most flows complete before they exit slow-start phase.
  5. Large queueing delay: TCP fills up any amount of buffering  
available at the bottleneck links. Results in long latency.
  6. Unfair bandwidth sharing: shares bandwidth inversely  
proportional to flow RTTs

  -Nandita

>
> Lets see if we can reach consensus on these two issues in a week's  
> time.
> These will also form parts 1 and 2 of the consensus document. I ask  
> for your
> co-operation in keeping the discussion to these two issues.
>
> thanks
>
> kesahv


Nandita Dukkipati
Graduate Student
Computer Systems Lab
Stanford University

webpage: http://yuba.stanford.edu/~nanditad/


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20060204/d8110abd/attachment.html