Re: [Dart] Add text OPS-Dir review of dscp-rtp draft ?

Ben Campbell <> Fri, 10 October 2014 19:33 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id F39461ACF02 for <>; Fri, 10 Oct 2014 12:33:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.686
X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ioX4nssuw4l0 for <>; Fri, 10 Oct 2014 12:33:24 -0700 (PDT)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 125071ACF05 for <>; Fri, 10 Oct 2014 12:33:15 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.14.9/8.14.7) with ESMTP id s9AJX7jm055281 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 10 Oct 2014 14:33:10 -0500 (CDT) (envelope-from
X-Authentication-Warning: Host [] claimed to be []
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ben Campbell <>
In-Reply-To: <>
Date: Fri, 10 Oct 2014 14:33:07 -0500
X-Mao-Original-Outgoing-Id: 434662387.57961-212cce0b52561fae86cd63bd38ad24b7
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: "Black, David" <>
X-Mailer: Apple Mail (2.1878.6)
Cc: "" <>
Subject: Re: [Dart] Add text OPS-Dir review of dscp-rtp draft ?
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 10 Oct 2014 19:33:27 -0000

Hi David,

I agree in principle, but I am not sure I agree the usage of "real-time" is precisely that of rfc1633. For example, the RAI area description says:

> The Real-Time Applications and Infrastructure (RAI) Area develops protocols and architectures for delay-sensitive interpersonal communications. Work in the RAI Area serves an industry whose applications and services include voice and video over IP, instant messaging, and presence. These applications and services are "real-time" in the sense described in RFC 3550.

Real-time applications as in 3550 sometimes, but not always, need network guarantees as in 1633. (There's _lots_ of RTP running over best-effort networks.)

It might be more precise to say that we are talking about (or at least charted to talk about) RFC 3550 applications that also qualify as real-time according 1633, but that the concepts may also apply to other applications that qualify as real-time as according to rfc1633.

(I have a feeling we're putting too fine a point on this.)

On Oct 8, 2014, at 11:22 PM, Black, David <> wrote:

> Fred Baker's OPS-Dir review of the dscp-rtp can be found here:
> I want to thank Fred for his positive opinion of the draft and ask the WG
> whether any of the descriptive text from this paragraph of Fred's review
> (which was intended primarily as background info for the OPS Directorate
> members) ought to be picked up by the draft:
>   As noted in its introduction, "This memo covers the implications of these
>   DiffServ aspects for real-time network communication, including WebRTC
>   traffic [I-D.ietf-rtcweb-overview]." The different "diffServ aspects" in
>   question are the implications of running an application that aggressively
>   marks its traffic for different network treatment in a best effort network
>   - one in which traffic may be routinely reordered, duplicated, or lost in
>   transit. If different DSCP marks result in different routing or the uses
>   of different queues and therefore competing with different and potentially
>   changing data flows ambient in the network, one would expect any such
>   interactions to be exaggerated; for example, if multi-topology routing is
>   used and some data flows take wildly different routes than others, one
>   could readily imagine a packet in each data flow sent simultaneously
>   arriving spaced tens or hundreds of milliseconds apart. While it is not
>   referenced in the document, the term "real-time" as used here is defined
>   in RFC 1633, and refers to an application that requires that the network
>   make specific guarantees to it, whether in end to end delay, minimum
>   delivery rate, or both. The term is generally understood to refer to
>   voice and video services, but can also refer to telemetry or other
>   traffic loads.
> My initial inclination is to pick up (in edited form) the text on the meaning
> of the term "real-time", including its reference to RFC 1633.
> Thoughts?
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
>        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
> _______________________________________________
> Dart mailing list