Re: [Dart] IPv6 Flow labels? (Re: RTP and non-RTP traffic on same UDP 5-tuple)

[Brian E Carpenter <[e-mail]>]

Hi Harald,

On 12/06/2014 23:40, Harald Alvestrand wrote:
> Brian,
> 
> you mentioned 6-tuples - with the link you gave, I assume you're talking
> about IPv6 flow labels.
> 
> Apart from the issues with remapping, the use of flow labels should have
> many of the same aspects as the use of DSCP codepoints.
> 
> Can you give us some idea of how the use (or not) of multiple flow
> labels within a 5-tuple has been thought about in the IPv6 context?

It hasn't, because the model is that the label will be the same for all
packets in a given flow, and a flow is usually assumed to be identified
by its 5-tuple. But there are words at the very beginning of RFC 6437
that intentionally leave room for breaking that assumption:

> 1.  Introduction
> 
>    From the viewpoint of the network layer, a flow is a sequence of
>    packets sent from a particular source to a particular unicast,
>    anycast, or multicast destination that a node desires to label as a
>    flow.  From an upper-layer viewpoint, a flow could consist of all
>    packets in one direction of a specific transport connection or media
>    stream.  However, a flow is not necessarily 1:1 mapped to a transport
>    connection.

So the door is open for multiple labels for the same 5-tuple, but always
remembering that the label might be used as part of a load-balancing
mechanism (as discussed in RFC 6438 and RFC 7098).

Also, here's the bad news, remapping cannot be completely excluded
for the flow label. See http://tools.ietf.org/html/rfc6437#section-6
and in particular http://tools.ietf.org/html/rfc6437#section-6.1

   Brian
> 
>        Harald
> 
> 
> On 06/11/2014 10:42 PM, Brian E Carpenter wrote:
>> On 11/06/2014 07:59, Black, David wrote:
>>> In another message, Ruediger Geib asked (>), and I responded:
>>>
>>> --------------------
>>>
>>>> Is the following correct:
>>>>
>>>> UDP_5-tuple-+--transport protocol 1-----
>>>>              |
>>>>              +--RTP session 1-----
>>>>              |
>>>>              +--RTP session 2-----+---RTP_stream_2.1
>>>>                                   |
>>>>                                   +---RTP_stream_2.2
>>>>                                   |...
>>> Yes, that matches my understanding, although the author team would
>>> like to
>>> see discussion of whether it's a good idea to mix RTP and non-RTP
>>> protocols
>>> on the same 5-tuple - I'll copy your useful diagram into a separate
>>> message
>>> to start that discussion.
>>>
>>> --------------------
>>>
>>> This is that message, and I want to thank Ruediger for drawing that
>>> useful
>>> diagram.
>>>
>>> The author team for draft-york would like input on whether the draft
>>> should
>>> discuss mixing of RTP and non-RTP traffic on the same UDP 5-tuple,
>>> vs. using
>>> separate 5-tuples (probably separate UDP ports) for RTP and non-RTP
>>> traffic.
>> One observation is that we should be thinking about a 6-tuple these
>> days (see RFC 6437). I don't think it makes much difference to the
>> argument.
>>
>> Another observation is when load balancing is in play, things get a bit
>> more complicated, but to a first approximation using the same 5-tuple
>> or 6-tuple will usually ensure that all the packets reach the same
>> load-balanced destination, which is probably a good thing.
>>
>> Third, reverting to the diffserv discussion, the same 5-tuple
>> should ensure that all the packets would be classified the same
>> (if they cross a diffserv domain boundary and get reclassified).
>>
>>      Brian
>>
>>> RTCWEB clearly intends to mix SCTP (via DTLS) and RTP traffic on the
>>> same
>>> 5-tuple see the last paragraph of Section 3.5 of
>>> draft-ietf-rtcweb-transports-04:
>>>
>>>     RTCWEB implementations MUST support multiplexing of DTLS and RTP
>>> over
>>>     the same port pair, as described in the DTLS_SRTP specification
>>>     [RFC5764], section 5.1.2.  All application layer protocol payloads
>>>     over this DTLS connection are SCTP packets.
>>>
>>> OTOH, concerns have been expressed about whether the not-exactly-elegant
>>> demux processing specified in the reference (RFC 5764, Section 5.1.2)
>>> ought
>>> to be recommended as a good way of doing this multiplexing.
>>>
>>> Please comment, including whether mixing SCTP and RTP on the same UDP
>>> 5-tuple is a good idea (some rationale for doing this sort of
>>> multiplexing
>>> onto a single 5-tuple can be found in Section 3 of
>>> draft-york-dart-dscp-rtp-00).
>>>
>>> Thanks,
>>> --David
>>> ----------------------------------------------------
>>> David L. Black, Distinguished Engineer
>>> EMC Corporation, 176 South St., Hopkinton, MA  01748
>>> [phone]             FAX: [phone]
>>> [e-mail]        Mobile: [phone]
>>> ----------------------------------------------------
>>>
>>>
>>> _______________________________________________
>>> Dart mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dart
>>>
>> _______________________________________________
>> Dart mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dart
> 
> _______________________________________________
> Dart mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dart
>