El 19/04/2005, a las 16:15, Iljitsch van Beijnum escribió:
On 19-apr-05, at 15:35, marcelo bagnulo braun wrote:
If we want to use the flow label for this we only need to change the
flow label sematics every so slightly so the flow label is unique
for a set of source/dest locators belonging to the same source and
dest hosts rather than source/dest addresses. Not too unreasonable,
IMO.
Right, but i guess that what Pekka was pointing out is that, in the
case that the locator set are dynamic, you don't know when the
locator set will overlap in the future (because an locator that is
already present in one context is added to another one in the
future), so it is not possible to make sure that the flow id is not
repeated in two different contexts whose locator set overlap. Hence
the problem.
Well, there are 1048575 possible flow label values so it's not
necessary to reuse the same one for a new session all that quickly.
The limitation is that the same flow label can't be used for a
different session to the same shim-enabled destination host
(regardless of address), for sessions to the same source/dest address
pair for non-shim-enabled hosts and for sessions to ANY host where the
shim-enabled status is unknown. Since presumably, we're going to find
out whether a certain correspondent host is shim-enabled or not sooner
rather than later, I don't see how this set of limitations can lead to
trouble other than the general downside of adding some complexity.
so quoting Pekka's initial mail on the thread:
- in step 3. above, an implementation could also perform two-tiered
reservation: first reserve the flow label for any communication,
but when in the danger of running out, start using it also for
those destinations that don't belong to the locator set. This way
this would not be an issue (albeit difficult to debug) until the
hosts are so loaded that they're running out of the flow label
space for their sessions.
seems the reasonable choice if the flow id approach imho