[xcp] Embedding XCP signalling in IP header

[Marko Zec]

On Thursday 19 August 2004 13:31, Tim Shepard wrote:
> > > OK, why not use some mechanism (IPv4 option or TCP option, it doesn't
> > > seem to matter) to query the other end's ability to use XCP and then
> > > when you get an affirmative response, switching to an XCP header that
> > > sits between IPv4 and IPv6?  That seems much simpler to me.
> >
> > That would certainly be nice. But what if hosts decide to do the switch,
> > but the path appears to be not XCP-capable? What about firewalls / NATs,
> > traffic engineering / policy based routing schemes etc. which might all
> > be making decisions based on the protocol field in the IP header, which
> > would be changed once the switch from TCP to XCP would be made? And how
> > would all this stuff be implemented on end nodes (switching the
> > encapsulation method in the middle of a connection)? All those issues do
> > not look that simple to me...
>
> [ah, I missed this the first time it went by, and wound up replying to
> later messages without having seen this context.  -Tim]
>
>
> The middlebox questions are certainly relevant.
>
> The middlebox questions are relevant for your incompatible reuse of
> the fragmentation fields also.  Traffic engineering or policy based
> routing schemes that look beyond the IP header to peek at the TCP port
> numbers will be broken by the non-zero fragment offset fields.  NATs
> and firewalls will also be confused by the apparently fragmented
> packets that they are receiving.  Some firewalls reassemble IP
> fragments so that they can inspect the content before forwarding the
> packet on.


Most of those issues could be dealt with using a simple hack. Instead of only 
sending a single XCP-CPR probe with all MF and Frag Offset bits cleared, end 
hosts would be required to also transmit an XCP-CPR frame (preferably MTU 
sized) with some predefined magic-cookie value written into MF/FO fields. 
Only after the other peer would confirm successfull reception of both types 
of XCP-CPR probes, the host could start using XCP signalling. Otherwise, it 
would consider the path to be incapable of transferring XCP traffic, and 
would continue to use plain old TCP instead.


> Middleboxes will be a challenge for XCP whatever the encoding scheme
> may be.


True. But different encoding schemes will encounter different problems.


> >  And how would all this
> > stuff be implemented on end nodes (switching the encapsulation method in
> > the middle of a connection)? All those issues do not look that simple to
> > me...
>
> I don't see what would be difficult for endnode stacks to handle a
> switch in encapsulation method (TCP/IP to TCP/XCP/IP) after an initial
> SYN SYN-ACK exchange.  It seems simpler to do that then switch the
> semantics of the IPv4 fragmenation-related fields in the middle of a
> connection.


Well, it doesn't seem simpler to me at all. For switching the frag field 
semantics on the fly you would only need two or three additional boolean 
variables per connection and a couple of conditional statements somewhere in 
tcp_input() and tcp_output() code. What would it take to implement the model 
you are proposing?

Anyhow, without prototype implementations, we both have no proper arguments in 
support of our views on this one...


> A separate header between IP and TCP with a new protocol number in the
> IP header is unambiguous to anyone trying to debug why some middlebox
> or endhost stack is not cooperating.


The proposed encoding scheme can be easily distinguished from the standard IP 
header format by observing the "reserved, should be zero" flag, which now has 
to be set for any XCP signalling. Why would that be ambiguous?

Marko