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

Re: Flow label - the problem

Hi Iljitsch,

El 21/04/2005, a las 12:42, Iljitsch van Beijnum escribió: 

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.


Ok, no arguing that extra overhead is bad, but keep in mind that the overhead is only cause when there is a rehoming event i.e. that the locator being carried is different from the ULID of the session.

(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.)

...

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.

Not sure if a agree here.
I mean, are you cosnidering the case where new locators can be added after the context has been established?
I mean, the requirement is to verify that those context that have intersecting locator set use different flow id values.

so if you are assuming that we have an static set of locators, then this is easy, since you can verify it when the session is established.

However if you assume dynamic locator sets, then this is simply impossible, since you cannot possible verify what will happen in the future i.e. if some of the locators included in one context won't be later on added to another context that has the same flow id value associated.

Now what you can do is to simply assign different flow id values. the problem is when you ran out of those. I guess we need to asses how likely is the situation when a hosts run out of flow ids values, and that there is an actual clashing of flow ids between session sharing locators and what is the effect of this situation (probably the addition of the repeated locator cannot be accepted in the other session, i guess). Imho the critical point is to evaluate this trade off here.

In addition there is the incapability of using previously unkown locators directly in data packets (perhaps this could be addressed, since the data packet would also have to contain validation infromation for the new locator, so proessing before the shim header would result in adding the new locator to the locator set avaialble for the session)

Regards, marcelo

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.