[Iccrg] Explicit feedback

[Doan B. Hoang]

Tony Li wrote:

> 
>
>  
>
>>>verifiability perspective.  Any in-band packet 
>>>      
>>>
>>modifications (e.g., RFC
>>    
>>
>>>3168 ECN) are problematic because packet header examination and
>>>modification is typically done on the ingress side of the 
>>>      
>>>
>>router, prior
>>    
>>
>>>to the actual switching of the packet.  For scalability reasons,
>>>maintaining full active queue state on the input side of 
>>>      
>>>
>>the system is
>>    
>>
>>>challenging, as the queues only truly exist on the output side.
>>>      
>>>
>>This part interests me: why is this a problem?
>>Is it because separate hardware pieces are involved on the ingress
>>and egress side, where every such piece (chip) would do all the
>>necessary work for one link only?
>>    
>>
>
>
>Typical high end routers now are designed for tens or hundreds of
>thousands of queues.   Some systems are probably well over a million.
>The egress side has queue information that it needs to propagate in
>real-time to the ingress side over an unreliable medium.  This is
>certainly solvable, but it comes at a price in bandwidth and mechanism,
>multiplied by scale and timeliness.  Justifying that cost is, IMHO, very
>hard.
>
>Tony
>
>  
>
Monitoring queue length this way does not scale and very expensive. One 
should consider
per interface queue length rather than numerous individual queues.

I believe that it is better to deal with congestion control at two 
levels (at least): the network
level and the transport level.
The transport level never works well if the network level cannot handle 
congestion properly.
For example, TCP traffic cannot compete with UDP traffic since there is 
no cooperation
between sources. Furthermore, per-TCP flow congestion control is not 
scalable (ECN
modification for example).
Current congestion control at the network level (IP) is implicit and 
does not contain adequate
information for sources to react.

We are considering Explicit Rate, per-Ingress-Egress congestion control 
for traffic classes (DSCP-like)
plus associated admission control. This information will be used by the 
transport protocol to handle its
own flow.

Doan

>
>_______________________________________________
>Iccrg mailing list
>Iccrg at cs.ucl.ac.uk
>http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>  
>

-- 
Doan B. Hoang	
URL: http://research.it.uts.edu.au/arn