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

[Ben Campbell <[e-mail]>]

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 <[e-mail]> wrote:

> 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
> [phone]             FAX: [phone]
> [e-mail]        Mobile: [phone]
> ----------------------------------------------------
> 
> _______________________________________________
> Dart mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dart