Subject: [Dart] FW: I-D Action: draft-york-dart-dscp-rtp-00.txt

From: "Black, David" <[email-masked]>
Date: Fri, 6 Jun 2014 21:04:53 -0400

On behalf of the author team, here's an initial -00 draft for
consideration by the dart WG.  Please keep in mind that this is a -00
draft, so it really is a "draft".

I should be embarrassed that it appeared to take a public nudge from a
past IETF Chair (Harald) to get this draft to appear, (Aside: if you'd
like that ability, send your name to the NomCom this year - they're
always looking for interested candidates for all positions), but the
fact of the matter is that more than one of us had the experience of
life being what happens while one is busy making other plans.

Comments and feedback are welcome and encouraged.

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
----------------------------------------------------

-----Original Message-----
From: I-D-Announce [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, June 06, 2014 8:49 PM
To: [email-masked]
Subject: I-D Action: draft-york-dart-dscp-rtp-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : Differentiated Services (DiffServ) and Real-time Communication
        Authors         : Dan York
                          David Black
                          Cullen Jennings
                          Paul Jones
	Filename        : draft-york-dart-dscp-rtp-00.txt
	Pages           : 13
	Date            : 2014-06-06

Abstract:
   This document describes the interaction between Differentiated
   Services (DiffServ) network quality of service (QoS) functionality
   and real-time network communication, including communication based on
   the Real-time Transport Protocol (RTP).  DiffServ is based on network
   nodes applying different forwarding treatments to packets whose IP
   headers are marked with different DiffServ Code Points (DSCPs).  As a
   result, use of different DSCPs within a single traffic flow may cause
   transport protocol interactions (e.g., due to reordering).  In
   addition, DSCP markings may be changed or removed between the traffic
   source and destination.  This document covers the implications of
   these DiffServ aspects for real-time network communication, including
   RTCWEB.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-york-dart-dscp-rtp/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-york-dart-dscp-rtp-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Ben Campbell <[email-masked]>
Date: Fri, 6 Jun 2014 20:22:57 -0500

Thanks David!

> On Jun 6, 2014, at 8:04 PM, "Black, David" <[email-masked]> wrote:
> 
> Dart mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dart

---

From: Ben Campbell <[email-masked]>
Date: Sun, 8 Jun 2014 23:26:02 -0500

Hi,

The referenced draft is a start for discussion on the implicat ions of using different DiffServ treatments for packets in the same IP flow (that is, share the same IP 5-tuple.) This will likely be of interest to RTCWEB, MMUSIC, AVTCORE, CLUE and possibly other groups that contemplate the bundling of multiple media streams on a single IP flow. 

Please take discussion to the DART working group list (copied.)

Thanks!

Ben.

---

From: Ben Campbell <[email-masked]>
Date: Sun, 8 Jun 2014 23:27:49 -0500

[Resending with the correct address for avtcore. Apologies for the repeat]

Hi,

Thanks!

Ben.

---

From: <[email-masked]>
Date: Tue, 10 Jun 2014 10:18:15 +0200

Hi David,

thanks, your team created a well written draft. 

If a MediaStream is carried in a RTP session, the text may also explicitely say that 
(it says MediaStreamTrack == media flow, which is carried in an individual RTP 
packet stream)

Is the following correct:

UDP_5-tuple-+--transport protocol 1-----
            |
            +--RTP session 1-----
            |
            +--RTP session 2-----+---RTP_stream_2.1
                                 |
                                 +---RTP_stream_2.2
                                 |...

This is impressive on first sight for a non-application expert. If the number of RTP (and other
transport) streams is high, I doubt that DiffServ is able to support more than rough 
differentiation. DiffServ is designed to aggregate traffic of similar requirements. Fine grained 
differentiation should be part of the application.

The question coming to my mind is, whether your team can add a statement how many AF classes are 
useful to carry different RTP sessions within one UDP flow. I'd be happier to live without a hen 
and egg problem (meaning app developers to wait for the transport guys to provide a set of 
defined classes and transport guys waiting for app developers to demand a number of defined 
classes).

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: Dart [mailto:[email-masked]] Im Auftrag von Black, David
Gesendet: Samstag, 7. Juni 2014 03:05
An: [email-masked]
Betreff: [Dart] FW: I-D Action: draft-york-dart-dscp-rtp-00.txt

On behalf of the author team, here's an initial -00 draft for consideration by the dart WG.  Please keep in mind that this is a -00 draft, so it really is a "draft".

I should be embarrassed that it appeared to take a public nudge from a past IETF Chair (Harald) to get this draft to appear, (Aside: if you'd like that ability, send your name to the NomCom this year - they're always looking for interested candidates for all positions), but the fact of the matter is that more than one of us had the experience of life being what happens while one is busy making other plans.

Thanks,
--David

-----Original Message-----
From: I-D-Announce [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, June 06, 2014 8:49 PM
To: [email-masked]
Subject: I-D Action: draft-york-dart-dscp-rtp-00.txt

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: "Black, David" <[email-masked]>
Date: Tue, 10 Jun 2014 15:44:22 -0400

Hi Ruediger,

> thanks, your team created a well written draft.

Great - thanks for taking a look.
 
> If a MediaStream is carried in a RTP session, the text may also explicitely
> say that (it says MediaStreamTrack == media flow, which is carried in an
> individual RTP packet stream)

As I read Section 11 of draft-ietf-rtcweb-rtp-usage-15, for RTCWEB,
that would happen only when the MediaStream contains exactly one
MediaStreamTrack.  The use of these terms in bullet item 1 in section 2
is intended to be specific to RTCWEB, but we could add text elsewhere to
point out that non-RTCWEB usage of MediaStreams could use an RTP packet
stream for each Media Stream, independent of how many MediaStreamTracks
each MediaStream contains.

Could you suggest a reference that could be cited for usage of an RTP
packet stream for each MediaStream independent of how many
MediaStreamTracks each MediaStream contains?

>             +--RTP session 2-----+---RTP_stream_2.1

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.

> The question coming to my mind is, whether your team can add a statement how
> many AF classes are useful to carry different RTP sessions within one UDP
> flow.

See draft-ietf-tsvwg-rtcweb-qos-00, which proposes to make all four AF
classes available, so we can expect that someone will try to use all of
them (and everything else in that draft).

OTOH, we did put this warning text in at the end of Section 2.4 of draft-york:

   Backbone and other carrier networks may employ a small number of
   DSCPs (e.g., less than half a dozen) in order to manage a small
   number of traffic aggregates; hosts that use a larger number of DSCPs
   may find that much of the intended differentiation is removed by such
   networks.

What additional text would you suggest that we add?

Thanks,
--David

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, June 10, 2014 4:18 AM
> To: Black, David
> Cc: [email-masked]
> Subject: AW: I-D Action: draft-york-dart-dscp-rtp-00.txt
> 
> Hi David,
> 
> On behalf of the author team, here's an initial -00 draft for consideration by
> the dart WG.  Please keep in mind that this is a -00 draft, so it really is a
> "draft".
> 
> I should be embarrassed that it appeared to take a public nudge from a past
> IETF Chair (Harald) to get this draft to appear, (Aside: if you'd like that
> ability, send your name to the NomCom this year - they're always looking for
> interested candidates for all positions), but the fact of the matter is that
> more than one of us had the experience of life being what happens while one is
> busy making other plans.
> 
> Internet-Draft directories: http://www.ietf.org/shadow.html or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: <[email-masked]>
Date: Wed, 11 Jun 2014 10:08:55 +0200

Hi David,

my responses start by "RG".

Regards, Ruediger

 > If a MediaStream is carried in a RTP session, the text may also 
 > explicitely say that (it says MediaStreamTrack == media flow, which is 
 > carried in an individual RTP packet stream)

DB: As I read Section 11 of draft-ietf-rtcweb-rtp-usage-15, for RTCWEB, 
DB: that would happen only when the MediaStream contains exactly one 
DB: MediaStreamTrack.  The use of these terms in bullet item 1 in 
DB: section 2 is intended to be specific to RTCWEB, but we could add 
DB: text elsewhere to point out that non-RTCWEB usage of MediaStreams 
DB: could use an RTP packet stream for each Media Stream, independent 
DB: of how many MediaStreamTracks each MediaStream contains.

DB: Could you suggest a reference that could be cited for usage of an 
DB: RTP packet stream for each MediaStream independent of how many 
DB: MediaStreamTracks each MediaStream contains?

RG> Sorry, I can't, that above was an assumption. I'd appreciate another 
    draft line explaining how MediaStream corresponds to RTP stream or 
    RTP session.

>             +--RTP session 2-----+---RTP_stream_2.1

[snip]

DB: See draft-ietf-tsvwg-rtcweb-qos-00, which proposes to make all four AF 
DB: classes available, so we can expect that someone will try to use all 
DB: of them (and everything else in that draft).

DB: OTOH, we did put this warning text in at the end of Section 2.4 of draft-york:

DB: What additional text would you suggest that we add?

RG> tsvwg-rtcweb-qos offers 4 priorities which, following the definition given 
    there, are relevant to the browser (not to forwarding, as the draft doesn't 
    change existing standards on that).
    I'd expect priorities "very low" and "low" to be produced in one queue. I'd 
    expect each AF class to be produced in one queue. So packet reordering may 
    occur between different priorities. Type "data" requires 3 queues, if 
    produced as I'd assume.

RG> Your draft is offering good QoS related guidance, and it's not only provided by the 
    above section. I would appreciate a good explanation of what to expect within 
    a single 5 tuple flow (a single application flow or multiple ones). I'd 
    further appreciate, if all rtcweb related drafts in the transport area clarify 
    the concepts they support related to rtcweb transport flow types. MF based 
    classification is one mode of DiffServ operation and it's important to note 
    whether this is applicable in future or not. For the time being, application 
    servers aren't always marking flows and the above suggests, that they will 
    have to mark packets within flows individually.

RG> Finally, if the QoE suffers because code points interpreted as application 
    priorities by browsers, which at the same time are interpreted as transport 
    QoS marks by routers which may be changed at network boundaries, then 
    DiffServ as a whole may have to be re-thought. To better understand that 
    point, I've posted a mail on the tsvwg list.

Regards,

Ruediger

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 11 Jun 2014 13:09:19 +0200

> MediaStreamTracks each MediaStream contains?

Careful - "RTP packet stream" is one of those concepts that can be 
meaningless without citing a specific definition.

draft-ietf-avtext-rtp-grouping-taxonomy is probably the best reference 
at the moment. It says this about "Packet stream":

2.1.10.  Packet Stream

    A stream of RTP packets containing media data, source or redundant.
    The Packet Stream is identified by an SSRC belonging to a particular
    RTP session.  The RTP session is identified as discussed in
    Section 2.2.2.

Under this definition, it's impossible to put more than one 
MediaStreamTrack into a packet stream.
In a lot of cases (FEC, redundancy, SVC, simulcast), there will be 
multiple RTP packet streams associated with one MediaStreamTrack.

The term is used only once in the draft, but unfortunately defines a new 
term to mean the same thing:

    The most common protocol used for real time media is the Real-Time
    Transport Protocol (RTP)[RFC3550].  RTP defines the mechanism by
    which real-time data is transmitted between hosts on the Internet.
    With most applications, a single media type (e.g., audio) is
    transmitted within a single RTP session.  However, it is possible to
    transmit multiple, distinct media flows over the same RTP session as
    individual RTP packet streams.  This is referred to as RTP
    multiplexing.

    For the purposes of this draft, the term "media flow" refers to a
    sequence of packets that is transmitted as a single RTP packet
    stream.

The term "media flow" doesn't sound to me like a good term to use for 
this concept.
Would the authors be willing to consider switching to "packet stream"?

---

From: "Black, David" <[email-masked]>
Date: Wed, 11 Jun 2014 10:10:45 -0400

Harald,

> meaningless without citing a specific definition.

+1

> at the moment. It says this about "Packet stream":

Thank you for the pointer, we'll be happy to cite and use that definition.

> The term "media flow" doesn't sound to me like a good term to use for this concept.

Speaking only for myself, I don't think so, because there are two
different concepts involved - IMHO, this draft needs two terms to refer to:

	a) What the application sends.
	b) How RTP carries that traffic.

"RTP packet stream" is clearly the right RTP term for the latter, and the
draft was written that way.  I would've liked to have used "media stream"
for the former, but W3C has defined MediaStream to not be a single stream
of media (go figure ...).  "media flow" seemed to be as good a term as
any for that concept, and "media flow" is already used for that concept
in draft-ietf-tsvwg-rtcweb-qos (i.e., it was not invented for this draft).

If you have an alternative term, please suggest it ... and then the authors
of any other draft that uses "media flow" (starting w/the rtcweb-qos draft)
will have to go make corresponding changes.

Thanks,
--David

> From: Dart [mailto:[email-masked]] On Behalf Of Harald Alvestrand
> Sent: Wednesday, June 11, 2014 7:09 AM
> To: [email-masked]
> Subject: Re: [Dart] I-D Action: draft-york-dart-dscp-rtp-00.txt
>

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 11 Jun 2014 16:21:54 +0200

> in draft-ietf-tsvwg-rtcweb-qos (i.e., it was not invented for this draft).
Yes - except that every time it's used in draft-york, including in the 
place it is defined, it means "RTP packet stream". If you are trying to 
use it for the stuff that's inside the RTP packets instead of the RTP 
packet streams, the definition needs to say so.

"Media source" is the term I think you're thinking of in -taxonomy- that 
corresponds more closely to the term - the complexifier is all the cases 
where a single media source is carried over multiple packet streams.

---

From: "Black, David" <[email-masked]>
Date: Wed, 11 Jun 2014 10:43:22 -0400

> packet streams, the definition needs to say so.

Ok, will try to clarify - I'll put this on the list of things to do in
the -01 version, including making sure it lines up well with the
rtcweb-qos draft.

> where a single media source is carried over multiple packet streams.

IMHO, "Media source" sounds like the sender, not what is sent.  MediaStream
seems to be a term for that what is sent that could be carried as multiple
RTP packet streams.

Thanks,
--David

> Sent: Wednesday, June 11, 2014 10:22 AM
> To: [email-masked]
> explicitely

---

From: "Black, David" <[email-masked]>
Date: Wed, 11 Jun 2014 22:34:22 -0400

Hi Ruediger,

Extracting text on a couple of points:

>     I'd appreciate another

Sure.  The parenthetical text on MediaStream and MediaStreamTrack can
be pulled out of item 1, moved a bit later in the section and expanded.

> RG> Your draft is offering good QoS related guidance, and it's not only
> 	provided by the above section. I would appreciate a good explanation
>	of what to expect within a single 5 tuple flow (a single application
>	flow or multiple ones).

That expectation may not be what you're looking for - it's likely to be
a longer version of "everything depends on the network(s)", i.e., nothing
can be assured in general, depending on how the networks involved are
configured for DiffServ.  See Brian Carpenter's recent emails to the list
and my comment on strengthening the text in Section 2.4 about how
differentiation can be lost (e.g., all traffic in a 5-tuple could be
remarked to DF [best effort] at some intermediate network boundary node).

Thanks,
--David

> Sent: Wednesday, June 11, 2014 4:09 AM
> To: Black, David
> Cc: [email-masked]

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 15 Jun 2014 04:04:52 +0000

------ Original Message ------
From: "Harald Alvestrand" <[email-masked]>
To: [email-masked]
Sent: 6/11/2014 7:09:19 AM
Subject: Re: [Dart] I-D Action: draft-york-dart-dscp-rtp-00.txt

>at the moment. It says this about "Packet stream":

Indeed.  I threw my two cents in on the word "Packet Stream". I spoke 
with (at least some of) the authors asking them to call this "RTP Packet 
Stream" or to pick something entirely different.  Between "packet 
stream" and "MediaStream" and "Media Stream" (yeah, those are different, 
too), the language makes it hard to follow.

>Would the authors be willing to consider switching to "packet stream"?

I don't have a strong preference, except that I'd prefer to qualify that 
as "RTP Packet Stream".

Paul

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Sun, 15 Jun 2014 05:20:56 +0000

On Jun 15, 2014, at 12:04 AM, Paul E. Jones <[email-masked]> wrote:

>> Careful - "RTP packet stream" is one of those concepts that can be meaningless without citing a specific definition.
>> 
>> draft-ietf-avtext-rtp-grouping-taxonomy is probably the best reference at the moment. It says this about "Packet stream":
>> 
> 
> Indeed.  I threw my two cents in on the word "Packet Stream". I spoke with (at least some of) the authors asking them to call this "RTP Packet Stream" or to pick something entirely different.  Between "packet stream" and "MediaStream" and "Media Stream" (yeah, those are different, too), the language makes it hard to follow.

Your issue has been understood and will be addressed.  In fact, Bo has already sent an email confirming that this change will be made for the next version:

"Change the term “Packet Stream” to “RTP Stream” throughout the document, since “Packet Stream” is too unspecific"

Cheers,

Gonzalo

> I don't have a strong preference, except that I'd prefer to qualify that as "RTP Packet Stream".
> 
> Paul
>

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 15 Jun 2014 09:19:04 +0200

> "Change the term “Packet Stream” to “RTP Stream” throughout the document, since “Packet Stream” is too unspecific"

That should be "RTP packet stream", with a specific reference to -taxonomy-.

"RTP Stream" is *less* specific than "packet stream".

-- 
Surveillance is pervasive. Go Dark.