Flow label - the problem

[Iljitsch van Beijnum <iljitsch@muada.com>]

You guys are making all of this WAY too difficult.

The problem we have to deal with is the possibilities of two  
transport-level sessions that share the same shim6 association using  
different ULIDs.

One way to deal with this is to forbid it. So implementations would  
have to choose source and destination ULIDs and stick with those for  
any particular shim6 association. However, this is bad for load  
balancing and it's possible that two sessions to different ULIDs turn  
out to terminate on the same host unexpectedly, in which case a full  
shim6 association wouldn't be able to form.

However, a good way to enforce this is to disallow overlap between  
ULIDs and additional locators. So if a host sees prefixes A and B, it  
forms four addresses:

A::ULID
A::locator-for-B
B::ULID
B::locator-for-A

Another way is to allow more than a single shim6 association at one  
time between two hosts, or to have transport sessions with different  
ULIDs within a single association. In this case there are four ways  
to determine the right ULID set:

1. An extension header or destination option
2. "stolen bits"
3. Port numbers
4. The flow label

I'm very much opposed to 1. because I think SOMEONE has to care about  
the overhead/payload ratio. Don't forget we're already moving from 20  
bytes for IPv4 to 40 bytes for IPv6. Then there is TCP which is  
another 20 bytes, the timestamp option that many OSes ALWAYS use  
regardless of whether it's appropriate (12 bytes) and of course lower  
layer overhead. If you look at the web for instance you'll see that  
*many* pages use a plethora of 0.1 KB images. It costs several  
kilobytes in mostly HTTP overhead to request those images.

But it's not just the overhead. The problem is that adding bytes to  
the packet increases the work that must be done per packet. This is  
also very bad.

(BTW using 128 bits or even 64 is way too many as you can't have  
lookup tables this large. 4 to 6 bytes would be more in line with 8  
more bytes in the header.)

Erik has looked at stealing bits from the protocol field. The problem  
is that this isn't very clean and the number of bits that can be  
found this way is small. The main advantage would be to be able to  
have routers rewrite addresses, but that's not on the table right now.

Looking at the port numbers is quite natural especially in an  
integrated tcp/ip implementation where this needs to happen at some  
point anway. The trouble is that not all protocols have and/or expose  
protocol numbers. For IPsec there is the SA of course, but there are  
some protocols that don't have anything equivalent. However, some  
limitations for these protocols would presumably be acceptable if it  
means good performance for TCP, UDP and other more common transports.

Then there is the flow label. This is pretty much an optimization of  
case 3, with two added bonusses: the flow label can be found in a  
fixed place in the packet, and it applies to all transports.

As I said before, the only thing needed to make the flow label usable  
for this, and without taking away from its other uses, is avoid  
reusing flow labels for sessions with an unknown shim6 status. For  
known non-shim sessions the current rules apply and for known shim  
sessions the current rules also apply except that the full address  
sets for both ends must be considered one address for flow label  
selection purposes. Yes, this is a little more work but it's per  
session rather than per packet so it's not so bad.