[xcp] Embedding XCP signalling in IP header
zec at icir.org
Wed Aug 18 15:27:45 PDT 2004
On Wednesday 18 August 2004 19:49, Bob Braden wrote:
> *> http://tel.fer.hr/zec/xcp-hdr-encoding.txt
> *> Would this make any sense?
> Nice try, but unfortunately, there are a lot of things wrong with your
> 1. I am much bemused (but not amused) by the irony of your citing
> Stoica's SFQ thesis as justification. In fact, Stoica wrote up his
> protocol as an Internet Draft and submitted it to the RFC Editor for
> publication as a non-IETF RFC. The RFC Editor was delighted to be able
> to publish such a substantive piece of research. But first, we had to
> get approval from the IESG for publication. The IESG stomped all over
> it and blocked its publication as an RFC, exactly on the grounds that
> it misused the fragmentation fields in IP. So, forget using the IP
I didn't intend to use Stoica's work as justification at all, just thought it
would be fair to give man a credit for the original idea. CSFQ prototype
implementation fiddles with Fragment Offset fields on packets traversing the
routers, which significantly differs from my proposal, where the use of FO
fields is determined explicitely and exclusively by end hosts. Isn't that
quite a different story?
As explained in my previous answer to Tim Shepard's question, I tried to be a
little bit more carefull not to abuse the Fragment Offset field. The message
format was carefully chosen not to allow any overloading of the FO field
until the transmitting host can be sure its peer is XCP capable, in which
case there would be no danger at all of reusing the FO field for other
purposes. Further, I assume we can all agree that originating end hosts are
already allowed to write random data to the IP ID field, so at least this
part of my scheme shouldn't be considered abusive, I guess.
In my view the real issue lies in the use of the "reserved, must be zero" flag
(bit #40 in the IP header). The question is will this bit remain reserved
for ever, or can we consider giving it some usefull purpose after all those
> 2. The format you give would be a horror to implement efficiently in
> high-capacity routers. Router vendors would just walk away.
> 3. We don't really know whether the floating-point representation you
> suggest will actually work, from a numerical analysis viewpoint.
> However, in any case it's almost certainly too hard to implement for
> a high-capacity router.
The floating point format is intended to be used only for storing the data in
the header. The fields have first to be converted to plain integers on which
all further math will be performed, just like in the original XCP protocol
proposal. My draft already describes how FP to integer format conversion can
be accomplished using only a few simple and more importantly fast
instructions (bit shifting etc.). It will certainly work fast using
general-purpose CPU-s. I assume those operations are simple enough that they
can be implemented as efficiently, if not faster, in any ASIC design.
What my document did not describe was integer to FP format conversion. This
can also be implemented using only a few instructions. Even finding a base-2
logarithm, which is a necessary step for such a conversion, can be completed
in a single clock tick using specialized machine instructions (such as bsrl
on IA-32 platforms). Again, hardware-assisted implementations could most
probably work only faster.
Of course it would be much easier to defend the thesis / hunch that the
proposed encoding scheme wouldn't introduce a significant processing
overhead, by using some quantitative data... Perhaps even that could be
arranged, if performance alone would be pinpointed as a key argument against
the proposed scheme...
> 4. It's a kludge.
> Nice writeup, though.
> Bob Braden
More information about the xcp