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

["Black, David" <[e-mail]>]

Hi Ruediger,

Extracting text on a couple of points:

>     I'd appreciate another
>     draft line explaining how MediaStream corresponds to RTP stream or
>     RTP session.

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

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Wednesday, June 11, 2014 4:09 AM
> To: Black, David
> Cc: [e-mail]
> Subject: AW: I-D Action: draft-york-dart-dscp-rtp-00.txt
> 
> 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.
> 
> > Is the following correct:
> >
> > UDP_5-tuple-+--transport protocol 1-----
> >             |
> >             +--RTP session 1-----
> >             |
> >             +--RTP session 2-----+---RTP_stream_2.1
> >                                  |
> >                                  +---RTP_stream_2.2
> >                                  |...
> 
> [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:
> 
>      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.
> 
> 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
> 
> 
>