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

Re: Flow label - the problem

Iljitsch van Beijnum wrote: 
On 21-apr-2005, at 13:11, marcelo bagnulo braun wrote:

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.


You still need to work your way through each packet to see if there is a header, so it's still bad even if the header isn't there... 

Er, every node has to step through all Next Headers anyway, whether or
not there is an extra header there.


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?


In general: yes. There may be some corner cases, though. Are you thinking about the situation where a locator that first belongs to one host later belongs to another host? 

Bingo. That's the point about virtualized IP addresses in a rack of
servers - addresses may well jump from box to box, or be created
and destroyed.


I mean, the requirement is to verify that those context that have intersecting locator set use different flow id values.


How can different associations have overlapping locator sets? 

If incoming traffic for virtual address X in a rack of servers is
assigned dynamically when a new session starts, it may be assigned
to different boxes for different sessions. Same thing for virtual
address Y and virtual address Z. So you end up with {X,Y} and {X,Z}
being locator 2-tuples for two different boxes, and then {X,Y,Z} is not
a valid locator 3-tuple. The fact that locator sets intersect does
not mean that you can form their union.

   Brian


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.


But the problem only exists when we have communication with the locator in question beforehand. So what would have to happen is that there is shim6 communication between two hosts, but there is also communication from one host to a locator without shim6, and then that locator is bound to the existing shim6 association. I agree that this can happen, but only for a very limited time: either the shim6- agnostic session will start up shim6 negotiations, or the existing association will add the new locator.

In other words: sessions move out of the state where their flow label can't be reused for other sessions fairly quickly because either they turn out shim-enabled and then we know the set of locators for which the flow label must remain unique, or they turn out shim-incable and the flow label can be reused for any other destination address.