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