Re: [Dart] RTP and non-RTP traffic on same UDP 5-tuple

<Ruediger.Geib@telekom.de> Thu, 12 June 2014 10:56 UTC

Return-Path: <Ruediger.Geib@telekom.de>
X-Original-To: dart@ietfa.amsl.com
Delivered-To: dart@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 443C41B29E7 for <dart@ietfa.amsl.com>; Thu, 12 Jun 2014 03:56:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.901
X-Spam-Level:
X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhe2M1c09k5x for <dart@ietfa.amsl.com>; Thu, 12 Jun 2014 03:56:06 -0700 (PDT)
Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 541791A0340 for <dart@ietf.org>; Thu, 12 Jun 2014 03:56:06 -0700 (PDT)
Received: from he111631.emea1.cds.t-internal.com ([10.134.93.23]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 12 Jun 2014 12:56:04 +0200
Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE111631.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 12 Jun 2014 12:56:03 +0200
From: <Ruediger.Geib@telekom.de>
To: <dwing@cisco.com>, <david.black@emc.com>
Date: Thu, 12 Jun 2014 12:56:03 +0200
Thread-Topic: [Dart] RTP and non-RTP traffic on same UDP 5-tuple
Thread-Index: Ac+F+m/mSow1rHq3Tni8QbdOzYy6eAAGgMcA
Message-ID: <CA7A7C64CC4ADB458B74477EA99DF6F502D063B365@HE111643.EMEA1.CDS.T-INTERNAL.COM>
References: <8D3D17ACE214DC429325B2B98F3AE712076FD346C9@MX15A.corp.emc.com> <5398BF50.5040604@gmail.com> <657B1854-CC2F-4061-83BF-43447230ACC3@cisco.com> <8D3D17ACE214DC429325B2B98F3AE712076FD348FF@MX15A.corp.emc.com> <94627BFD-C142-4092-BC9D-920B802C01D5@cisco.com> <8D3D17ACE214DC429325B2B98F3AE712076FD34914@MX15A.corp.emc.com> <6FCE9946-352C-4174-8760-88BE6A16373C@cisco.com>
In-Reply-To: <6FCE9946-352C-4174-8760-88BE6A16373C@cisco.com>
Accept-Language: en-US, de-DE
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, de-DE
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dart/bfwXpkwW3Y6wBVBwlPPgUiiFPnk
Cc: dart@ietf.org
Subject: Re: [Dart] RTP and non-RTP traffic on same UDP 5-tuple
X-BeenThere: dart@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" <dart.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dart>, <mailto:dart-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dart/>
List-Post: <mailto:dart@ietf.org>
List-Help: <mailto:dart-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dart>, <mailto:dart-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Jun 2014 10:56:09 -0000

Dan, David,

to be a bit more specific about the constraints: if certain PHBs 
and may be DSCPs are desired, then we will have to standardize 
them and pay attention to the way they are produced in different 
network sections along an end to end path.

It came to my mind that your draft deals with some DiffServ related 
constraints and my other mail wasn't explicit.

Regards,

Ruediger


-----Original Message-----
From: Dart [mailto:dart-bounces@ietf.org] on behalf of Dan Wing
Sent: Thursday, 12. June 2014 06:55
To: Black, David
Cc: dart@ietf.org
Subject: Re: [Dart] RTP and non-RTP traffic on same UDP 5-tuple


On Jun 11, 2014, at 7:37 PM, Black, David <david.black@emc.com> wrote:

>> Is the problem lack of color awareness in the AF remarker, or that AF 
>> remarkers assume all packets in the 5-tuple have the same color?
> 
> The former, quoting from Section 2.4 of the draft:
> 
>   In addition, remarking may remove application-level distinctions in
>   forwarding behavior - e.g., if multiple PHBs within an AF class are
>   used to distinguish different types of frames within a video flow,
>   token-bucket-based remarkers operating in Color-Blind mode (see
>   [RFC2697] and [RFC2698] for examples) may remark solely based on flow
>   rate and burst behavior, removing the drop precedence distinctions
>   specified by the source.

So, from a DSCP perspective, there won't be a problem mixing traffic needing different DSCP in the same 5-tuple.

> Beyond that, if the network that the traffic is entering does not 
> support the AF class involved on that ingress, DSCP remarking to zero 
> (best effort) is a likely behavior.

Sure.  Only fix there is to restore the DSCP by some other sort of signaling.  Which means separate 5-tuples (to make such signaling straight forward) or requiring network gear to peek deeper into the packets to restore the DSCP bits, such as distinguish STUN/DTLS/RTP packets from each other, and if RTP to use the solution-de-jour for how to identify more-important RTP packets from less-important RTP packets (such as RTP header extension which has been bantered about, or DPI).  

Hoping DSCP is preserved or re-written without semantic loss seems a long-dead pipe dream.  I would like to work towards solutions that allow the receiver to indicate their desired behavior for treatment on the receiver's network, rather than the sender specifying.  But probably out of scope of DART, I suppose.

-d



> 
> Thanks,
> --David
> 
> 
>> -----Original Message-----
>> From: Dan Wing [mailto:dwing@cisco.com]
>> Sent: Wednesday, June 11, 2014 10:00 PM
>> To: Black, David
>> Cc: dart@ietf.org
>> Subject: Re: [Dart] RTP and non-RTP traffic on same UDP 5-tuple
>> 
>> 
>> On Jun 11, 2014, at 5:58 PM, Black, David <david.black@emc.com> wrote:
>> 
>>>> What do you mean by 'all the packets would be classified the same'?  
>>>> If you mean all the packets in a 5-tuple would get the same 
>>>> differentiated
>> treatment,
>>>> that is not desirable, because there are lots of folks wanting to 
>>>> send
>> video
>>>> i-frames or packets with FEC or other stuff with lower drop 
>>>> precedence than other packets.
>>> 
>>> That would most likely be within an AF class; the entire set of 
>>> packets
>> marked
>>> w/different drop precedences within an AF class should be classified 
>>> the
>> same.
>>> 
>>> Beyond that, one can hope that any AF remarker (e.g., for traffic 
>>> shaping)
>> is
>>> running in Color-Aware mode and hence tries to preserve source drop
>> precedence
>>> distinctions, but this cannot be relied upon.
>> 
>> Is the problem lack of color awareness in the AF remarker, or that AF 
>> remarkers assume all packets in the 5-tuple have the same color?
>> 
>> -d
>> 
>> 
>>> Thanks,
>>> --David
>>> 
>>>> -----Original Message-----
>>>> From: Dan Wing [mailto:dwing@cisco.com]
>>>> Sent: Wednesday, June 11, 2014 8:32 PM
>>>> To: Brian E Carpenter
>>>> Cc: Black, David; dart@ietf.org
>>>> Subject: Re: [Dart] RTP and non-RTP traffic on same UDP 5-tuple
>>>> 
>>>> 
>>>> On Jun 11, 2014, at 1:42 PM, Brian E Carpenter
>> <brian.e.carpenter@gmail.com>
>>>> 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).
>>>> 
>>>> What do you mean by 'all the packets would be classified the same'?  
>>>> If you mean all the packets in a 5-tuple would get the same 
>>>> differentiated
>> treatment,
>>>> that is not desirable, because there are lots of folks wanting to 
>>>> send
>> video
>>>> i-frames or packets with FEC or other stuff with lower drop 
>>>> precedence than other packets.
>>>> 
>>>> -d
>>>> 
>>>> 
>>>>> 
>>>>>  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
>>>>>> +1 (508) 293-7953             FAX: +1 (508) 293-7786
>>>>>> david.black@emc.com        Mobile: +1 (978) 394-7754
>>>>>> ----------------------------------------------------
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> Dart mailing list
>>>>>> Dart@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/dart
>>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Dart mailing list
>>>>> Dart@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/dart
>>> 
> 

_______________________________________________
Dart mailing list
Dart@ietf.org
https://www.ietf.org/mailman/listinfo/dart