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

Re: Flow label - the problem

Iljitsch van Beijnum wrote: 
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.

I don't think we can forbid this, since it is the applications/ULPs that select at least the destination ULID, and in some cases the source ULID as well.

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

I wouldn't say that this is forbidding the applications from selecting the ULID. Instead I view this as a different way to carry information to the receiver to help it disambiguate the packets (and what rewriting is needed before passing the packets to the ULP); you are effectively carrying that information in the IP address fields.

Another way is to allow more than a single shim6 association at one time between two hosts,

I don't understand how this would work.
Whether or not there is a single shim6 association isn't the key issue.
The issue is that the receiver will need to handle packets with the same locator pair in them, where some of them need to have those locators replaced with different ULIDs before passing them to the ULP.
To do this there has to be something in the packet that can distinguish the packets. Could be by effectively carrying the disambiguating information in the address fields as you suggest above, the flow label, or some separate context tag carried in the packet. And this extra information can be skipped when the receiver doesn't have to rewrite the address fields.

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:

   Erik