[Iccrg] Explicit feedback

[Michael Welzl]

On Mon, 2006-08-07 at 00:43, 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.

Thanks for elaborating! So, just to see if I got that right:
what you're saying means that:

1. RED is much easier to deploy without ECN than it is with ECN

2. Explicit feedback that is not based on the current outbound
   queue length might be easier to deploy

... obviously, with 2, the question arises: what else could
we feedback to sources?

What about a traffic measurement from the ingress link, such
as MIB2-ifInOctets but obviously with a rule that these data
must be updated whenever explicit signaling is requested -
would that be more or less effort than feedback that is based
on egress queue information?

Cheers,
Michael