[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: shim header in every shimmed packet

Iljitsch van Beijnum wrote:
And of course, it doesn't get any simpler than simply putting in an explicit shim6 header with the context tag in every shimmed packet. This is what's on the table now. 

Iljitsch,
it is not in every packet.
It is only in packets after a locator switch i.e., when the IPv6 source and/or destination are different then the ULIDs.
The question is of course whether saving 8 bytes on shimmed packets is worth the trouble relative to the added complexity of having packets with or without the header. It looks that to a large degree, this is a matter of personal taste. We're essentially increasing overhead on IPv6 by at least 1% (7.7% to 8.7% for two 1500 byte TCP packets + an ACK).
Looks like you are assuming that there will be failures all the time so that NO packet will have ULIDs=locators. If that level of failures was common in the Internet today, then I suspect we'd spend most of our time waiting for BGP to converge instead of sending emails to each other :-) 


> So in these cases it makes sense to suppress the shim header. Now
> obviously it may be tricky to determine exactly when the receiver  will
> or won't need the shim header, but the good part is that we  don't have
> to figure that out now. What I'm arguing for is a  capability that
> allows a receiver to let the sender know it doesn't  need the shim
> header for a certain context (when there are no  extension headers). So
> the only thing we need is specify a capability  bit in the initial shim
> exchange that signals this, and require that  implementations suppress
> the shim header when the bit indicates this  is desired.
Isn't the receiver's ability to demux the packets to the correct context without the context tag a function of the locator sets and ULIDs that are in use? 
If so I don't see how a single bit can suffice.
It seems like one would need to at a minimum covey that bit in the Update Ack message (in addition to the context establishment) so that when the peer changes its locators, the host can restate whether or not it can demux without the context tag for the new set of locators.
But the current design also uses uncoordinated teardown of the context state, which can result in one end not having any context state any more, even though the peer might send packets using that context. With the context tag in the packets that need to be rewritten by the receiver, we can detect this condition. But your 'single bit' scheme would seem to need some different way to detect this missing state. Any ideas on how to do this? 

   Erik