[Iccrg] Explicit feedback

[Tony Li]

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.

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
>