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

From: "Black, David" <[email-masked]>
Date: Thu, 9 Oct 2014 04:22:29 +0000

Fred Baker's OPS-Dir review of the dscp-rtp can be found here:
	http://www.ietf.org/mail-archive/web/ops-dir/current/msg00504.html

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
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: Ben Campbell <[email-masked]>
Date: Fri, 10 Oct 2014 14:33:07 -0500

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 <[email-masked]> wrote:

> _______________________________________________
> Dart mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dart