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

Harald Alvestrand <harald@alvestrand.no> Thu, 12 June 2014 10:47 UTC

Return-Path: <harald@alvestrand.no>
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 63A281B29E5 for <dart@ietfa.amsl.com>; Thu, 12 Jun 2014 03:47:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 0piNiBIohCqn for <dart@ietfa.amsl.com>; Thu, 12 Jun 2014 03:47:21 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 7915A1A0390 for <dart@ietf.org>; Thu, 12 Jun 2014 03:47:21 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id C92877C3811 for <dart@ietf.org>; Thu, 12 Jun 2014 12:47:20 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2kSIwsIdWMl for <dart@ietf.org>; Thu, 12 Jun 2014 12:47:20 +0200 (CEST)
Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by mork.alvestrand.no (Postfix) with ESMTPSA id 0C5D97C3804 for <dart@ietf.org>; Thu, 12 Jun 2014 12:47:20 +0200 (CEST)
Message-ID: <53998537.6080700@alvestrand.no>
Date: Thu, 12 Jun 2014 12:47:19 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: dart@ietf.org
References: <8D3D17ACE214DC429325B2B98F3AE712076FD346C9@MX15A.corp.emc.com> <5398BF50.5040604@gmail.com> <657B1854-CC2F-4061-83BF-43447230ACC3@cisco.com> <8D3D17ACE214DC429325B2B98F3AE712076FD348FF@MX15A.corp.emc.com> <53990684.8050900@gmail.com>
In-Reply-To: <53990684.8050900@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dart/EtUItjXk8HSzcvI3ffGDVinP7Xk
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:47:24 -0000

On 06/12/2014 03:46 AM, Brian E Carpenter wrote:
> On 12/06/2014 12:58, Black, David 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.
> Indeed not, and that's on the assumption that the receiving domain
> even operates an AF service class. The worst case assumption is
> that everything reverts to best effort somewhere along the path.

That's a fairly benign case, actually.
The worst case is that DSCP priorities get remapped in a way that 
inverts drop precedence (see the draft's discussion about 
less-than-best-effort).

I hope that's not a case that's so frequent that we have to worry 
over-much about it.