[xcp] Embedding XCP signalling in IP header

[Matt Mathis]

I don't think this works unless you can absolutely disable fragmentation in 
both endpoints and the path.  I still do not understand all of the strangeness 
that middle boxes might attempt, but it could be argued that they are at least 
as wrong when something breaks.  Note that in most stacks fragment reassembly 
happens long before protocol dispatch and port matching (it has to!), which 
greatly complicates overloading the bits.

This also prevents XCP from being used under some middle services, e.g. NFS/UDP 
which typically relies on IP fragmentation as its packetization layer.  (Note 
that draft-mathis-pmtud-method-02.txt recommends and several OS's already set 
DF on IPv4 fragments to prevent re-fragmentation.)

It may be true that if MF and Frag Offset are both zero, then the IP ID is 
effectively unused and could be transparently redefined (possibly keyed on bit 
16 as well).  This slightly different way of specifying it (which may be the 
same as your proposal) has the advantage that it is stateless at the IP layer 
and interoperates with standard fragmentation, but the transport layer can 
detect corruption (e.g. unexpected fragmentation.) Note that if there is 
unexpected fragmentation and the IP ID is effectively constant, major data 
corruption is likely. See draft-mathis-frag-harmful-00.txt Down stream changes 
to the IP ID may also result in complete protocol failure.

If the transport protocol detects fragmentation, it should disable XCP on the 
fly...

I believe that this breaks header compression (it assumes roughly sequential IP 
IDs) and collides with at least one other proposal to overload IP ID.

Good luck,
--MM--
-------------------------------------------
Matt Mathis      http://www.psc.edu/~mathis
Work:412.268.3319    Home/Cell:412.654.7529
-------------------------------------------
"My heart is in the work." -- Andrew Carnegie

On Wed, 18 Aug 2004, Marko Zec wrote:

> On Wednesday 18 August 2004 19:14, Tim Shepard wrote:
>>> http://tel.fer.hr/zec/xcp-hdr-encoding.txt
>>
>> I very quickly skimmed your text.
>>
>> I believe this would be incompatible with current stacks.  Just
>> because the DF bit may be turned on does not mean that a host
>> receiving an IPv4 header with something other than zero in the MF and
>> Fragment Offset fields will ignore them.  I believe it will continue
>> to use those fields to reassemble the complete datagram.
>
>
> Good point. Here's how the proposed scheme takes care of this issue (copy and
> paste from the original draft):
>
> End nodes must maintain XCP capabilities state on per connection and per
> flow basis. That said, each end node is allowed to transmit only frames
> of Type 0 (XCP-CPR) until it has determined its peer is XCP capable.
>
>  XCP-CPR (capability probe) format:
>
>    0                   1                   2                   3
>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |0|0|0|0|R| Unu | Time To Live  |1|1|0|0|0|0|0|0|0|0|0|0|0|0|0|0|
>   | | | | |P| sed |     Check     | | | | | | | | | | | | | | | | |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>   Bit 4: (RP) Reverse Path 0 = not XCP capable, 1 = XCP capable.
>   Bits 8-15: (XCP-TTL) Time To Live Check
>
> XCP-CPR transmission:
>
>   The transmitting endpoint must fill in the fields in XCP-CPR header
>   as follows:
>
>   RP flag is set to the per-connection state indicating whether the
>   reverse path (from the receiver to the sender) is XCP capable.
>   Initially the node has no knowledge on network path capabilities, so
>   it must set the RP flag to zero.
>
>   XCP-TTL must be set to exactly the same value as in the standard IP
>   header TTL field.
>
>   All other bits have to be cleared, in order not to confuse receiving
>   endpoints incapable of XCP processing. Otherwise, such nodes might
>   interpret the Fragment Offset field, which would result in
>   transmitted packet ending up in the reassembly buffer and never
>   being propagated the upper protocol layer.
>
>
> So, in other words, the XCP-CPR message format has been choosen precisely to
> prevent non-XCP hosts from being fooled by receiving XCP messages. Once both
> peers confirm to each other they can speak XCP, there's no fear of
> misinterpretation of messages stored inside the Fragment Offset field, so we
> can then safely start using all those bits in XCP-FWD and XCP-RFL messages.
>
> Marko
>
>
>
>> In other
>> words, the DF bit means "do not fragment further".  You can still do
>> end-to-end fragmentation and reassembly with IPv4 and yet have the DF
>> bit turned on in all the packets carrying the fragments.
>>
>> (Can someone confirm this?)
>>
>> 			-Tim Shepard
>> 			 shep at alum.mit.edu
>