[Iccrg] Explicit feedback
tli at tropos.com
Sun Aug 6 23:43:12 BST 2006
> > 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
More information about the Iccrg