[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Flow label versus Extension header - protocol itself
On 7-mei-2005, at 1:31, Erik Nordmark wrote:
Anyway, in a post I don't think anybody read I suggested that we
should use a sort of demux negotation. Since demux can happen on:
- unique locator sets
- transport protocol information (port numbers)
- flow label
- demux option in the packet
I did read that message.
My concerns with this suggestion are:
1. Having multiple mechanisms plus some fallback rules seems very
complex. We should figure out how to make a single mechanism work.
Well, obviously a single mechanism is always gong to be less complex,
but what I'm proposing here really isn't all that bad. In its
simplest form, the receiver only has to transmit a fixed capabilities
message and demux based on a shim header. The sender needs to parse a
capabilities message and perform the following check:
if (demuxPossibleOnLocators() == true)
else if (demuxPossibleOnPort() == true && (proto == TCP || proto ==
However, the possible gains are substantial: implementers now get to
add unique locator / transport / flow label (de)multiplexing to their
stuff if and when it makes sense for them, and this capability will
be used whenever it's available at both ends.
Simply going for the option means adding bytes to all packets
forever. This is especially harmful when future developments such as
unreachable ULIDs or rehoming for traffic engineering purposes happen.
2. Peeking at the transport information is a no-no in my mind. We
want this to be transport independent.
There is a difference in using information when it's available and
depending on the information to be there.