Re: IPv6 Flow Label

[Brian E Carpenter <brian.e.carpenter@gmail.com>]

In line..

On 2008-05-07 15:34, Philip Matthews wrote:
> 
> On Tue, 6-May-08, at 21:41 , Brian E Carpenter wrote:
>> On 2008-05-07 06:35, Philip Matthews wrote:
>>> I would prefer that this thread not dissolve into a debate on whether or
>>> not there will be NATs in IPv6 networks. I would also prefer that this
>>> thread not discuss scenarios in which TURN might or might not be used in
>>> IPv6 scenarios.  If you wish, let's discuss these on other threads.
>>>
>>> In this thread, I would like to start with the assumption that TURN _is_
>>> being used to relay IPv6 to IPv6.  IF this is done, then what is the
>>> appropriate treatment for the flow label field?
>>>
>>> Right now, I see two alternatives:
>>>
>>> 1) Copy the flow label from the incoming packet to the outgoing packet
>>> if possible. If not possible (because the appropriate APIs do not exist
>>> on the OS on which the TURN server runs to allow the incoming flow label
>>> to be read), then treat each (client, peer) combination as defining a
>>> flow and assign unique flow labels correspondingly.
>>
>> I'm disturbed by the idea of copying the label. The rules
>> were designed in such a way that the 3tuple {DA, SA, flow label}
>> is bound to be unique, without any signaling, so that flows can
>> always be identified by any router they happen to go through.
>> So I think that any relay device that is not a simple packet
>> forwarder should assign a new flow label, to guarantee that
>> uniqueness.
>>>
>>> 2) Always set the outgoing flow label to 0.
>>
>> This is a subset of "assign a new flow label". Zero is always
>> allowed.
>>
>> The rules in RFC3697 were intended to make the flow label's
>> semantics robust even when there are different use cases
>> operating simultaneously. It could be the case (I'm making
>> this up) that the originating host wants to use flow labels
>> to support load-spreading, and the TURN relay wants to use
>> flow labels to support some future QOS mechanism. "Assign
>> a new flow label" works well in that case.
>>
>> So, I'd say that the default behavior for a relayed packet
>> should be "Assign 0", and "Assign a new flow label according to
>> RFC3697" should be optional (just as the whole of RFC3697 is optional).
>> And this is entirely independent of whether or not the incoming
>> packet has a non-zero flow label.
> 
> I have no technical problem with doing with you suggest.
> 
> My only question is: if many devices adopt this approach, then won't
> this mean that the flow label will often be zero, and thus useless for
> things like load-balancing in equal-cost multi-path scenarios?

That is today's situation - there was no consensus for assuming
that load-balancing is the primary use case, so no consensus for
making setting the label a SHOULD. I don't think that TURN is special
in this regard.

> 
>>
>>
>> (The same is not true of the DSCP. There's every reason that should
>> be copied as-is. But I expect you know that.)
> 
> The proposed DSCP text says that the DSCP should be copied unless the
> relay believes, through unspecified means, that another value for the
> outgoing DSCP is appropriate. However, if the incoming value cannot be
> read, then set the outgoing value to Best Effort (again, unless the
> relay believes another value is more appropriate).

OK, although I would be a bit more specific: unless the relay
includes a diffserv classifier (and associated policy). That's
how it obtains such a 'belief' in the diffserv model.

> Believe me, the v4 cases have had much discussion (including the
> involvement of three current ADs).

I don't doubt it ;-)

   Brian