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

Re: I-D ACTION:draft-nordmark-multi6dt-shim-00.txt

Erik,

Just responding on the flow label points:

Erik Nordmark wrote:
....

Brian E Carpenter wrote:

I think it depends where you sit. Above the shim, a flow
has to be identified using its ULID pair. Below the shim,
but in the hosts, we have the necessary state to use the
complex tuple. In routers along the way, we can only
identify flows in the traditional way.

This does need to be discussed in the draft, even before
we get to section 9.2.1.


In fact it is almost orthogonal to 9.2.1. 

Indeed. That's what I meant to say.

Even if the flow label is not used for demultiplexing, the draft should say how the shim handles the flow label.
I think the simplest approach is that the flow label is carried through as is. This means that the {Flow Label, Source ULID, Dest ULID} will appear on the wire as the set of {flow label, source locator, destination locator) for the different locator pairs. 

Yes, I see no alternative rule that can be implemented efficiently.


This does have implications for protocols which do explicit signaling to create flow state; such protocols would somehow need to be multi6 aware so that they can perform the signaling for all the locator pairs that are used on the wire. 

Yes. And I hear that NSIS has realised already that they interact
with multihoming - in fact one of the reasons we moved the session
back to Monday was to avoid a clash with NSIS.

... 

That isn't enough. As noted above, a flow label is only unique within
a {Flow Label, Source Address, Destination Address} 3tuple. And in
multi6, that surely has to be extended to any 3tuple in the complex tuple
{Flow Label, {Source Locators}, {Dest Locators}}. A slightly tricky
per-packet lookup, that won't be good for performance. But there is
good news just below...


You're right in the general case. However, one could further constrain flow label allocation for the hosts that implement multi6 so that for multi6 packets the receiver wouldn't have to compare the locators but only use the flow label. 

No, that doesn't work, because two quite independent source hosts might
choose the same flow label. You have no choice but to look at the source
locator as well as the label.

Note that due to deferred multi6 capability discovery this would have to apply to all flow label assignments on a host which implements multi6. And it being feasible doesn't mean it is a good idea :-) 

Well, I think you could reasonably require that a sender never uses the same
flow label twice at the same time (that is more constraining than the global
rule, but probably not a problem in a 20 bit space). But you don't need to.
You simply apply the normal rule - make it unique per source and dest ULID
pair. That should make it unique across the {{source locator},{dest locator}}
set anyway, and thats's all you need.


   determine the context to be used for the demultiplexing operation,
   hence determining the identifiers that have to be presented to the
   upper layers.  Because this approach overloads the Flow Label field,
   it is necessary to have an additional information to determine
   whether the Flow Label field is actually being used as a context tag
   or not.  In other words, additional information is needed to identify
   multi6 packets from regular IPv6 packets.  This is because, the same
   Flow Label value that is being used as context tag in multi6 enabled
   communication can be used for other purposes by a non-multi6 enabled
   host,




Good news. This is wrong (and I didn't realise it when analyzing NOID).

Flow Labels are not unique on their own and cannot be used for
anything on their own. You must always lookup a 3tuple.But if the
received  {Flow Label, Source Locator, Dest Locator} is in the set
{Flow Label, {Source Locators}, {Dest Locators}} corresponding to
a particular {Flow Label, Source ULID, Dest ULID} 3tuple, the shim
*knows* that it is a multi6 packet.


If the {flow label, src locator, dst locator} is used to identify the state then you are right. But that prevents a possible optimization with changing locator sets (think mobility) by requiring that multi6 signaling be complete to tell the peer of the new locator before that locator can be used as the source. 

But you MUST know the source locator in order to discriminate flow labels,
as mentioned above.


(The only extra rule at the source
to make this true is: never use the same flow label for a multi6 flow
and a non-multi6 flow to the same destination.)


I think things are harder than they look at first sight. 

Always :-) But the point here is that you have to deal with independent
sources that happen to choose the same flow label.


With deferred state creation, all flows are potentially multi6 flows, and furthermore the locator set for the peer isn't know until the deferred signaling exchange. This means the flow label needs to be unique across all communication at the sender I think.

Yes, but you have to know who the sender is...

Take host A communicating with foo.example and bar.example.
foo.example has ULID1 and ULID2 in the DNS. A picks ULID1 for the communication.
bar.example has ULID3 and ULID4 in the DNS. A picks ULID3 for this.
A starts communicating with both of them using some flow labels.
Later A decided independently that it is worth-while to setup multi6 state for ULID1 and ULID3. When doing so it discovers that it is in fact the same host, with 4 locators (ULID1 through 4).
If it had allocated the same flow label for some flow to ULID1 and some flow to ULID3, it is stuck; it must then constrain to use a subset of the locators for each ULID otherwise the receiver would but the wrong ULID in the packet.

So in this approach the only sane thing is for the sender to never reuse a flow label (where "never" is while there is existing communication, or there might be some multi6 state at a peer using that flow label), independently of the ULIDs being used. 

Agreed. The problem is if host B does the same thing and picks the same
flow label values by chance. That only works if foo and bar look at
the source locators too.


FWIW allocating a context tag, which goes in its own extension header,
when the multi6 state is created, and only using that extension header when the receiver needs to rewrite the address fields (i.e., after a rehoming event) is a lot simpler. Costs 8 bytes per packet but only after there has been a failure resulting in rehoming to different locators. 

I agree. There is just the minor MTU annoyance.

   Brian