[xcp] Notes from XCP meeting at ISI

[Tim Shepard]

> * Detecting Non-XCP routers
> 
> 	-- It will be important to detect non-XCP routers
> 		in the path.  For this purpose, we need a TTL field in the
> 		XCP header.  It will be initialized to the IP TTL, and
> 		each router's XCP will decrement it.  If there are only
> 		XCP routers, its value at the receiver will match the TTL
> 		in the IP header.
> 


Once again, my usual rant about this:

 Though this parallel TTL trick might have some value, it will not
 allow you to straightforwardly detect all of the non-XCP queues on
 the path.  (Ethernet switches, MPLS forwarders, etc) What should an
 XCP-aware router do if it is forwarding a packet to another XCP-aware
 router (one IPv[46] TTL hop) over a path that has contestable queues
 which are not XCP aware?  Should it in that case be configured to not
 decrement the TTL?  (I don't like where this thought is going.  How
 can the party responsible for configuring the router know for sure
 what non-IP-router queues might be between it and the next router?
 How can we depend upon the party responsible for configuring the
 router to get this configruation correct?  Ick.)

I see this as a problem, but am unsure what to do about it.  My hope
that someone clever can figure out how to let XCP co-exist with
traffic in non-XCP queues by using the dropped packets as a strong
hint that there's a non-XCP queue on the path which is currently the
bottleneck, and somehow behaving appropriately in that case.

I hope this inspires someone to invent a better scheme.
I'm guessing that a better scheme will make the TTL scheme unnecessary.

			-Tim Shepard
			 shep at alum.mit.edu