[Iccrg] Explicit feedback

[Doan B. Hoang]

Tony Li wrote:

>Michael,
>
>Would a former router vendor do?
>
>A complete answer to your query would probably be more lengthy than what
>you really intended, so I'm going to be relatively terse.  Please feel
>free to ask me to expound where it's of interest.
>
>Modern high end router design has a 100% pure hardware data path.  While
>some instantiations actually have some degree of programmability, there
>is nothing that looks like a general purpose processor executing
>arbitrarily complicated code anywhere near the average packet.
>
>Thus, what's realistic is extremely limited: any solution must not
>require significant state, as there is typically very little high speed
>memory available; any solution must also be relatively simple, both from
>a computational complexity point of view, as well as from a
>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.
>Out-of-band notification (e.g., ICMP source quench) is a security
>nightmare.  Interaction with MPLS needs to be thought through and fully
>specified.
>
>Finally, on the non-technical front, the system replacement cycle is on
>the order of five years, and router customer and router vendors need to
>be presented with a direct and immediate business case for any
>modifications.
>  
>
On this point I agree with Jon Crowcroft that any congestion control 
scheme must be inherent
and ready when it is required. Finding a good congestion control scheme 
should not start only
when the vendors need it (by yesterday not tomorrow).
See a discussion paper by Jon Crowcroft and his group:

Crowcroft, J., Hand, S., Mortier, R., Roscoe, T., Warfield, A. (2003). 
QoS's Downfall: At the bottom, or not at all! _ACM SIGCOMM 2003 
Workshop_. Karlsruhe, Germany.

Doan

>I don't mean to sound discouraging, but any changes at this point would
>be challenging.
>
>Regards,
>Tony
>
>
>  
>
>>-----Original Message-----
>>From: iccrg-bounces at cs.ucl.ac.uk 
>>[mailto:iccrg-bounces at cs.ucl.ac.uk] On Behalf Of Michael Welzl
>>Sent: Sunday, August 06, 2006 1:09 AM
>>To: iccrg
>>Subject: [Iccrg] Explicit feedback
>>
>>Hi,
>>
>>There is no doubt that explicit feedback from routers is useful
>>for a congestion control mechanism - this has been illustrated
>>by mechanisms like XCP and Quickstart (and several others).
>>
>>Yet, such mechanisms are critical because they require additional
>>work in routers. So what is realistic? How much extra effort
>>can one really assume from routers, when the scalability of
>>a mechanism must not be constricted? And how should the
>>provision of such feedback be specified - e.g. with pseudocode,
>>as in the appendix of the XCP paper, or something else...?
>>
>>This kind of knowledge is missing in the congestion control
>>landscape. Perhaps we can we make a change here.
>>
>>Presumably, the best answers would come from folks who
>>work for router vendors - do we have some here? If so,
>>could you please comment?
>>
>>Cheers,
>>Michael
>>
>>_______________________________________________
>>Iccrg mailing list
>>Iccrg at cs.ucl.ac.uk
>>http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>>
>>    
>>
>
>
>
>_______________________________________________
>Iccrg mailing list
>Iccrg at cs.ucl.ac.uk
>http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>  
>

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