[xcp] Embedding XCP signalling in IP header
braden at ISI.EDU
Thu Aug 19 09:48:45 PDT 2004
*> If you make the router XCP-aware, so that it's looking for the XCP
*> protocol ID in the IPv4 header, then if it slow-paths that, that would
*> be a deliberate choice of the designer of that IPv4 router. That
*> would be unfortunate. I sure hope that doesn't happen.
It is a lot less likely to happen if it is clear to the router
designers that the XCP-specific operations on each packet are very fast
and very simple. Doing fixed/floating conversions and doing complex
bit-wise packing and unpacking do not seem to qualify as fast or simple
to implement in existing technology. That was the basis for one of my
concerns about Marko's suggestion.
But there is a larger argument. John sort of hinted at it, but I am not
sure anyone has really enunciated it. History should make us wary of
assuming that Dina's XCP (whatever that is, specifically...) will be
the ultimate congestion control algorithm.
Our work at ISI has hinted (to me, at least) that there may still
problems with XCP in principle, and resolving them may require
changing not only the algorithms but also, perhaps, the precise
information carried in each packet. In other words, Dina's XCP may be
only the first in a family of congestion control protocols that use
per-flow information in each packet in conjunction with aggregate
calculations in the routers. Perhaps it would help if we called
Dina's protocol XCP1.
So, architecturally it would be foolish to shoe-horn the precise bits
of XCP1 into the IPv4 header. Our implementation of XCP already has
three different data encodings, I believe, and I expect we will add
several more before we are done, and these are for XCP.1 only. We need
a more general solution, which the layer 3+ approach provides. John
referred to it as a "larger next-header story".
BTW, the ISI group did give this matter some thought before choosing a
new XCP header between IP and the transport layer. We went through
all the arguments that have been discussed on this list, more or less.
Our sin is in not writing it down. :-(
*> reason to slow path in this case, then I would expect there would also
*> be a similar reason to slow-path the packets that carried the XCP
*> information in overloaded fragmentation fields.
*> -Tim Shepard
*> shep at alum.mit.edu
*> xcp mailing list
*> xcp at mailman.isi.edu
More information about the xcp