[xcp] Embedding XCP signalling in IP header

[John Wroclawski]

At 7:14 AM -0400 8/19/04, Tim Shepard wrote:
>>  Of course we should. But we should also not ignore that IPv4 is 
>>here to stay,
>>  and that the lack of compatibility with current IPv4/TCP stacks equals the
>>  inability to interact with any of the existing systems / applications. If we
>>  could gain that compatibility, XCP would certainly see a much 
>>faster path for
>>  wide deployment and acceptance. That's what my proposal was all about...
>
>
>I don't see how your proposal is better than putting the XCP header
>between the IPv4 header and the TCP header.
>
>In either case, there must be a mechanism that lets each end determine
>if the other end can switch in to our new special XCP mode (an extra
>header or your re-use of IPv4 fragmentation-related fields).  Once
>you've determined that the other end can handle XCP packets, then it
>hardly matters which method is used to carry the XCP information.
>

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)

cheers,
john