[xcp] Embedding XCP signalling in IP header
falk at ISI.EDU
Thu Aug 19 11:20:16 PDT 2004
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
> (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)
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?
More information about the xcp