[xcp] Embedding XCP signalling in IP header

[Marko Zec]

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
> approach.
>
> 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
> header.


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 
years?


> 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...

Best regards,

Marko



> 4. It's a kludge.
>
> Nice writeup, though.
>
> Bob Braden
>
>