[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Flow label - the problem
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
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:
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.