[xcp] Embedding XCP signalling in IP header
jtw at lcs.mit.edu
Thu Aug 19 07:09:21 PDT 2004
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
(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)
More information about the xcp