Re: Flow label versus Extension header - protocol itself

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

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)
  sendPacket();
else if (demuxPossibleOnPort() == true && (proto == TCP || proto ==  
UDP))
  sendPacket();
else
  sendPacketWithShim6Option();

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.