[xcp] Embedding XCP signalling in IP header

[Aaron Falk]

On Aug 19, 2004, at 7:09 AM, John Wroclawski wrote:

> One possible counter to this (although not the strongest one in the 
> world) is that reusing v4 header fields in a way that doesn't kick the 
> packet out of the fast path of existing routers is, other things being 
> equal, a pragmatically better decision than almost any other choice, 
> which might.
>
> This argument is based on two assumptions:
>
> - like any congestion control mechanism, XCP needs to be implemented 
> only at intermediate nodes where resources are actually scarce - some 
> people will choose the alternative approach of significant 
> overcapacity and simpler hardware.
>
> - any "odd" IP thing, such as use of a per-hop next-header mechanism 
> borrowed from v6, will kick the packet out of the fast path.
>
> I think that both of these assumptions aren't blanket truth, but both 
> also may have some validity.
>
> - Particularly during any (long..) transition to an XCP world, it's 
> critical that non-xcp nodes not arbitrarily be 1/100 as fast at 
> forwarding xcp-bearing pkts as non-xcp pkts. This is independent of 
> whether or not you believe that in the fullness of time there might 
> still be non-xcp routers at places where congestion is "impossible".
>
> - It's interesting to look at other contexts and see how narrow the 
> fast-path processing gets. People really do optimize only the cases 
> that they *know* already matter *today*. It seems to me that a very 
> likely scenario is that a box that understands next-header mechanisms 
> at all, but isn't specifically optimized for XCP,  will put in first 
> level hardware a simple test: "might I need to think more about this 
> packet", kicking the pkt to slow processing if the answer is yes. So 
> again a next-header based mechanism for XCP might cause these packets 
> to be processed much more slowly at some routers than a field-reuse 
> mechanism.
> (Another way to say this is that people may assume that once a router 
> decides it cares about a next-header at all, it's for a control 
> message, and so should definitely be slow-path)

John-

For the life of me, I can't tell from your reasoning whether you think 
that the embedded-L3 header solution is preferable to the L3.5 header 
we are using or not.  In both cases, non-XCP capable routers should 
ignore the extraneous (XCP) information.  Am I missing something?

--aaron