From nobody Mon Sep 1 04:11:06 2014 Return-Path: X-Original-To: dart@ietfa.amsl.com Delivered-To: dart@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD9E1A0362 for ; Mon, 1 Sep 2014 04:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6CBXFOP2GIVe for ; Mon, 1 Sep 2014 04:11:01 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08BEB1A0363 for ; Mon, 1 Sep 2014 04:11:01 -0700 (PDT) Received: from [130.209.247.112] (port=53723 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XOPVY-0002cp-Bs; Mon, 01 Sep 2014 12:10:57 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: Date: Mon, 1 Sep 2014 12:10:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <90176521-2804-4F23-908E-29827FADE1A6@csperkins.org> References: <8D3D17ACE214DC429325B2B98F3AE712077BC667DE@MX15A.corp.emc.com> <2B82DD06-83A4-4710-B614-16F5351A0A7F@nostrum.com> <8D3D17ACE214DC429325B2B98F3AE712077BC66841@MX15A.corp.emc.com> <54005A89.1030606@alvestrand.no> <8D3D17ACE214DC429325B2B98F3AE712077BC6691C@MX15A.corp.emc.com> <5400A1AB.6000600@alvestrand.no> <6521A08A-30A9-4805-9B84-41EC4376BDF6@csperkins.org> <5400D48A.30306@alvestrand.no> <8D3D17ACE214DC429325B2B98F3AE712077BC6699A@MX15A.corp.emc.com> <66D9B374-9647-4399-8467-71258705B525@nostrum.com> <5D845428-3E6D-43AC-978E-4754C627FD69@csperkins.org> To: Ben Campbell X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/dart/du42Ipw_vTtvYWVaQ0LOio6P0Ns Cc: Harald Tveit Alvestrand , "Black, David" , "dart@ietf.org" Subject: Re: [Dart] draft-dart-dscp-rtp - way forward X-BeenThere: dart@ietf.org 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: Mon, 01 Sep 2014 11:11:04 -0000 Ben, The guidance looks fine to me, but the explanatory text in the last = paragraph of Section 5.4 is perhaps not quite right. The text: This guidance may result in different DSCP markings for RTP streams and RTCP receiver reports about those RTP streams. The resulting variation in network QoS treatment by traffic direction could result in unrepresentative round trip time (RTT) estimates that don't correspond to consistent network QoS treatment in both directions. RTCP receiver reports may be relatively infrequent (e.g., may be sent only once per video frame rendered) and hence the resulting RTT estimates are of limited utility for congestion control (although they have other important uses, see [RFC3550]). For this reason, it is not important that RTCP receiver reports receive the same network QoS treatment as the RTP stream or streams being reported on. suggests that the RTT estimate derived from RTCP will be = unrepresentative, since it may not have consistent network QoS in each = direction. However, since the RTP media packets can use different QoS in = each direction, the RTCP also needs to do so, to be representative! If = the media used different QoS markings for different directions and the = RTCP used the same marking, the RTT estimate wouldn=92t match that of = the media.=20 I suggest the paragraph be changed to: This guidance may result in different DSCP markings for RTP streams and the RTCP packets reporting on those RTP streams. The resulting variation in network QoS treatment by traffic direction is necessary to get representative round trip time (RTT) estimates that correspond=20= to the media path RTT. RTCP receiver reports may be relatively = infrequent=20 and hence the resulting RTT estimates are of limited utility for = congestion=20 control (although they have other important uses, see [RFC3550]). = For this=20 reason, it is important that RTCP receiver reports sent by an SSRC = receive=20 the same network QoS treatment as the RTP stream being sent by that = SSRC. Colin On 31 Aug 2014, at 01:26, Ben Campbell wrote: > Colin and Harald, >=20 > I see David has submitted version 06. Can you verify that you are okay = with the language in this version?=20 >=20 > Thanks! >=20 > Ben. >=20 > On Aug 29, 2014, at 4:55 PM, Colin Perkins wrote: >=20 >> Without having seen the submitted version, this sounds okay. >>=20 >> --=20 >> Colin Perkins >> http://csperkins.org/ >>=20 >>=20 >>=20 >>> On 29 Aug 2014, at 21:16, Ben Campbell wrote: >>>=20 >>> Thanks, David! >>>=20 >>> Am I counting correctly that this would close the last substantive = open issue? If so, and if Harald and Colin confirm they are okay with = the change, we should be able to request publication for the upcoming = version, correct? >>>=20 >>> (I see that Harald expressed support as I am typing this...) >>>=20 >>> Thanks! >>>=20 >>> Ben. >>>=20 >>>> On Aug 29, 2014, at 3:09 PM, Black, David = wrote: >>>>=20 >>>> Ok, I see a range of views from skepticism to outright opposition = ... >>>>=20 >>>> I'll delete the paragraph and reference to the multi-stream = optimization >>>> draft and submit the resulting -06 version w/a change note that any = interaction >>>> of DiffServ and RTCP multi-stream optimization will be dealt with = in the draft >>>> about the latter. >>>>=20 >>>> That submission won't happen tonight, as the network in the SAS = Lounge in >>>> EWR isn't even close to what we're used to at IETF meetings :-). >>>>=20 >>>> Thanks, >>>> --David >>>>=20 >>>>> -----Original Message----- >>>>> From: Harald Alvestrand [mailto:harald@alvestrand.no] >>>>> Sent: Friday, August 29, 2014 3:29 PM >>>>> To: Colin Perkins >>>>> Cc: Ben Campbell; Black, David; dart@ietf.org >>>>> Subject: Re: [Dart] draft-dart-dscp-rtp - way forward >>>>>=20 >>>>>> On 08/29/2014 06:04 PM, Colin Perkins wrote: >>>>>>> On 29 Aug 2014, at 16:52, Harald Alvestrand = wrote: >>>>>>>> On 08/29/2014 05:14 PM, Black, David wrote: >>>>>>>> Harald, >>>>>>>>=20 >>>>>>>> I'm about to submit a -05 with the indication that the single = DSCP >>>>> recommendation for SCTP and DCCP may be revised. The RTCP = multi-stream >>>>> optimisation text will still be in there with Colin's = clarification about >>>>> "received" streams. I'm about to vanish for about 3 weeks, but = could put in a >>>>> revised -06 over the weekend if you can quickly convince Colin. >>>>>>> Explicitly pinging Colin - Colin, are you arguing that the = sentence >>>>>>>=20 >>>>>>> RTCP multi-stream reporting optimizations for an RTP session >>>>>>> [I-D.ietf-avtcore-rtp-multi-stream-optimisation] assume that the = RTP >>>>>>> streams involved experience the same packet loss behavior. This >>>>>>> mechanism is highly inappropriate when the RTP streams involved = use >>>>>>> different PHBs, even if those PHBs differ solely in drop = precedence. >>>>>>>=20 >>>>>>> should stay in the draft? >>>>>> I was, but thinking again, I'm not so sure. >>>>>>=20 >>>>>>> I think this recommendation is wrong. >>>>>>>=20 >>>>>>> I can't find anything in your latest messages that speak to this = particular >>>>> point. >>>>>>> You're one of the authors of -multi-stream, so you should be = able to speak >>>>> clearly to the point. >>>>>>>=20 >>>>>>> Can you clarify? >>>>>> If I have several SSRCs, and receive several media streams, then = provided >>>>> each of my SSRCs sees the exact same quality for each received = stream, then I >>>>> can use the multi-stream-optimisation to reduce the number of RTCP = cross >>>>> reports I send. The multi-stream-optimisation draft says that = already, and >>>>> it's not clear that the DART drafts needs to say anything further = on the >>>>> topic. >>>>>>=20 >>>>>> Whether I use the same DSCP for all RTCP reports I send is, I = think, >>>>> orthogonal to whether I use the multi-stream-optimisation. The = dart draft >>>>> should possibly say that, but I'm not sure that's the sentence we = have above. >>>>> I read the sentence above as saying flatly and unconditionally = "don't >>>>> use multi-stream-optimization when the RTP streams have different = PHBs" >>>>> - which means that if I want to use one PHB for audio and another = PHB >>>>> for video, I can't use multi-stream-optimization. >>>>>=20 >>>>> I'd be sad if that was the case, *especially* if we can't figure = out any >>>>> reason to make that recommendation. >>>=20 >>=20 >> _______________________________________________ >> Dart mailing list >> Dart@ietf.org >> https://www.ietf.org/mailman/listinfo/dart >=20 --=20 Colin Perkins http://csperkins.org/ From nobody Mon Sep 1 04:17:03 2014 Return-Path: X-Original-To: dart@ietfa.amsl.com Delivered-To: dart@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50DF41A038E for ; Mon, 1 Sep 2014 04:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wxr4PiresVvp for ; Mon, 1 Sep 2014 04:16:53 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE4D1A038F for ; Mon, 1 Sep 2014 04:16:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 1EB437C3F9C; Mon, 1 Sep 2014 13:16:47 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gm-hhB8yQUEW; Mon, 1 Sep 2014 13:16:44 +0200 (CEST) Received: from android-b42137fce5d2e3ef.homenet.telecomitalia.it (host26-139-static.241-95-b.business.telecomitalia.it [95.241.139.26]) by mork.alvestrand.no (Postfix) with ESMTPSA id 0BC5B7C3E10; Mon, 1 Sep 2014 13:16:43 +0200 (CEST) User-Agent: K-9 Mail for Android In-Reply-To: <90176521-2804-4F23-908E-29827FADE1A6@csperkins.org> References: <8D3D17ACE214DC429325B2B98F3AE712077BC667DE@MX15A.corp.emc.com> <2B82DD06-83A4-4710-B614-16F5351A0A7F@nostrum.com> <8D3D17ACE214DC429325B2B98F3AE712077BC66841@MX15A.corp.emc.com> <54005A89.1030606@alvestrand.no> <8D3D17ACE214DC429325B2B98F3AE712077BC6691C@MX15A.corp.emc.com> <5400A1AB.6000600@alvestrand.no> <6521A08A-30A9-4805-9B84-41EC4376BDF6@csperkins.org> <5400D48A.30306@alvestrand.no> <8D3D17ACE214DC429325B2B98F3AE712077BC6699A@MX15A.corp.emc.com> <66D9B374-9647-4399-8467-71258705B525@nostrum.com> <5D845428-3E6D-43AC-978E-4754C627FD69@csperkins.org> <90176521-2804-4F23-908E-29827FADE1A6@csperkins.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----8B8INSR2OAD19YE3272JSYWPYO2VKW" Content-Transfer-Encoding: 8bit From: Harald Alvestrand Date: Mon, 01 Sep 2014 13:16:39 +0200 To: Colin Perkins ,Ben Campbell Message-ID: <48683577-c891-4904-aaf9-7a17546d4231@email.android.com> Archived-At: http://mailarchive.ietf.org/arch/msg/dart/FsmlSnHFDQ74D7Jg6Vj9vMEQhao Cc: "Black, David" , "dart@ietf.org" Subject: Re: [Dart] draft-dart-dscp-rtp - way forward X-BeenThere: dart@ietf.org 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: Mon, 01 Sep 2014 11:16:57 -0000 ------8B8INSR2OAD19YE3272JSYWPYO2VKW Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 This illustrates well the thought that media RTT is not a good concept - each media stream goes only one way.... On 1. september 2014 13:10:41 CEST, Colin Perkins wrote: >Ben, > >The guidance looks fine to me, but the explanatory text in the last >paragraph of Section 5.4 is perhaps not quite right. The text: > > This guidance may result in different DSCP markings for RTP streams > and RTCP receiver reports about those RTP streams. The resulting > variation in network QoS treatment by traffic direction could result > in unrepresentative round trip time (RTT) estimates that don't > correspond to consistent network QoS treatment in both directions. > RTCP receiver reports may be relatively infrequent (e.g., may be sent > only once per video frame rendered) and hence the resulting RTT > estimates are of limited utility for congestion control (although > they have other important uses, see [RFC3550]). For this reason, it > is not important that RTCP receiver reports receive the same network > QoS treatment as the RTP stream or streams being reported on. > >suggests that the RTT estimate derived from RTCP will be >unrepresentative, since it may not have consistent network QoS in each >direction. However, since the RTP media packets can use different QoS >in each direction, the RTCP also needs to do so, to be representative! >If the media used different QoS markings for different directions and >the RTCP used the same marking, the RTT estimate wouldn’t match that of >the media. > >I suggest the paragraph be changed to: > > This guidance may result in different DSCP markings for RTP streams > and the RTCP packets reporting on those RTP streams. The resulting > variation in network QoS treatment by traffic direction is necessary > to get representative round trip time (RTT) estimates that correspond >to the media path RTT. RTCP receiver reports may be relatively >infrequent >and hence the resulting RTT estimates are of limited utility for >congestion >control (although they have other important uses, see [RFC3550]). For >this >reason, it is important that RTCP receiver reports sent by an SSRC >receive >the same network QoS treatment as the RTP stream being sent by that >SSRC. > >Colin > > > > >On 31 Aug 2014, at 01:26, Ben Campbell wrote: >> Colin and Harald, >> >> I see David has submitted version 06. Can you verify that you are >okay with the language in this version? >> >> Thanks! >> >> Ben. >> >> On Aug 29, 2014, at 4:55 PM, Colin Perkins wrote: >> >>> Without having seen the submitted version, this sounds okay. >>> >>> -- >>> Colin Perkins >>> http://csperkins.org/ >>> >>> >>> >>>> On 29 Aug 2014, at 21:16, Ben Campbell wrote: >>>> >>>> Thanks, David! >>>> >>>> Am I counting correctly that this would close the last substantive >open issue? If so, and if Harald and Colin confirm they are okay with >the change, we should be able to request publication for the upcoming >version, correct? >>>> >>>> (I see that Harald expressed support as I am typing this...) >>>> >>>> Thanks! >>>> >>>> Ben. >>>> >>>>> On Aug 29, 2014, at 3:09 PM, Black, David >wrote: >>>>> >>>>> Ok, I see a range of views from skepticism to outright opposition >... >>>>> >>>>> I'll delete the paragraph and reference to the multi-stream >optimization >>>>> draft and submit the resulting -06 version w/a change note that >any interaction >>>>> of DiffServ and RTCP multi-stream optimization will be dealt with >in the draft >>>>> about the latter. >>>>> >>>>> That submission won't happen tonight, as the network in the SAS >Lounge in >>>>> EWR isn't even close to what we're used to at IETF meetings :-). >>>>> >>>>> Thanks, >>>>> --David >>>>> >>>>>> -----Original Message----- >>>>>> From: Harald Alvestrand [mailto:harald@alvestrand.no] >>>>>> Sent: Friday, August 29, 2014 3:29 PM >>>>>> To: Colin Perkins >>>>>> Cc: Ben Campbell; Black, David; dart@ietf.org >>>>>> Subject: Re: [Dart] draft-dart-dscp-rtp - way forward >>>>>> >>>>>>> On 08/29/2014 06:04 PM, Colin Perkins wrote: >>>>>>>> On 29 Aug 2014, at 16:52, Harald Alvestrand > wrote: >>>>>>>>> On 08/29/2014 05:14 PM, Black, David wrote: >>>>>>>>> Harald, >>>>>>>>> >>>>>>>>> I'm about to submit a -05 with the indication that the single >DSCP >>>>>> recommendation for SCTP and DCCP may be revised. The RTCP >multi-stream >>>>>> optimisation text will still be in there with Colin's >clarification about >>>>>> "received" streams. I'm about to vanish for about 3 weeks, but >could put in a >>>>>> revised -06 over the weekend if you can quickly convince Colin. >>>>>>>> Explicitly pinging Colin - Colin, are you arguing that the >sentence >>>>>>>> >>>>>>>> RTCP multi-stream reporting optimizations for an RTP session >>>>>>>> [I-D.ietf-avtcore-rtp-multi-stream-optimisation] assume that >the RTP >>>>>>>> streams involved experience the same packet loss behavior. >This >>>>>>>> mechanism is highly inappropriate when the RTP streams involved >use >>>>>>>> different PHBs, even if those PHBs differ solely in drop >precedence. >>>>>>>> >>>>>>>> should stay in the draft? >>>>>>> I was, but thinking again, I'm not so sure. >>>>>>> >>>>>>>> I think this recommendation is wrong. >>>>>>>> >>>>>>>> I can't find anything in your latest messages that speak to >this particular >>>>>> point. >>>>>>>> You're one of the authors of -multi-stream, so you should be >able to speak >>>>>> clearly to the point. >>>>>>>> >>>>>>>> Can you clarify? >>>>>>> If I have several SSRCs, and receive several media streams, then >provided >>>>>> each of my SSRCs sees the exact same quality for each received >stream, then I >>>>>> can use the multi-stream-optimisation to reduce the number of >RTCP cross >>>>>> reports I send. The multi-stream-optimisation draft says that >already, and >>>>>> it's not clear that the DART drafts needs to say anything further >on the >>>>>> topic. >>>>>>> >>>>>>> Whether I use the same DSCP for all RTCP reports I send is, I >think, >>>>>> orthogonal to whether I use the multi-stream-optimisation. The >dart draft >>>>>> should possibly say that, but I'm not sure that's the sentence we >have above. >>>>>> I read the sentence above as saying flatly and unconditionally >"don't >>>>>> use multi-stream-optimization when the RTP streams have different >PHBs" >>>>>> - which means that if I want to use one PHB for audio and another >PHB >>>>>> for video, I can't use multi-stream-optimization. >>>>>> >>>>>> I'd be sad if that was the case, *especially* if we can't figure >out any >>>>>> reason to make that recommendation. >>>> >>> >>> _______________________________________________ >>> Dart mailing list >>> Dart@ietf.org >>> https://www.ietf.org/mailman/listinfo/dart >> > > > >-- >Colin Perkins >http://csperkins.org/ -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ------8B8INSR2OAD19YE3272JSYWPYO2VKW Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit This illustrates well the thought that media RTT is not a good concept - each media stream goes only one way....

On 1. september 2014 13:10:41 CEST, Colin Perkins <csp@csperkins.org> wrote:
Ben,

The guidance looks fine to me, but the explanatory text in the last paragraph of Section 5.4 is perhaps not quite right. The text:

   This guidance may result in different DSCP markings for RTP streams
   and RTCP receiver reports about those RTP streams.  The resulting
   variation in network QoS treatment by traffic direction could result
   in unrepresentative round trip time (RTT) estimates that don't
   correspond to consistent network QoS treatment in both directions.
   RTCP receiver reports may be relatively infrequent (e.g., may be sent
   only once per video frame rendered) and hence the resulting RTT
   estimates are of limited utility for congestion control (although
   they have other important uses, see [RFC3550]).  For this reason, it
   is not important that RTCP receiver reports receive the same network
   QoS treatment as the RTP stream or streams being reported on.

suggests that the RTT estimate derived from RTCP will be unrepresentative, since it may not have consistent network QoS in each direction. However, since the RTP media packets can use different QoS in each direction, the RTCP also needs to do so, to be representative! If the media used different QoS markings for different directions and the RTCP used the same marking, the RTT estimate wouldn’t match that of the media. 

I suggest the paragraph be changed to:

   This guidance may result in different DSCP markings for RTP streams
   and the RTCP packets reporting on those RTP streams.  The resulting
   variation in network QoS treatment by traffic direction is necessary
   to get representative round trip time (RTT) estimates that correspond 
   to the media path RTT. RTCP receiver reports may be relatively infrequent 
   and hence the resulting RTT estimates are of limited utility for congestion 
   control (although they
have other important uses, see [RFC3550]).  For this 
   reason, it is important that RTCP receiver reports sent by an SSRC receive 
   the same network QoS treatment as the RTP stream being sent by that SSRC.

Colin




On 31 Aug 2014, at 01:26, Ben Campbell <ben@nostrum.com> wrote:
 Colin and Harald,
 
 I see David has submitted version 06. Can you verify that you are okay with the language in this version? 
 
 Thanks!
 
 Ben.
 
 On Aug 29, 2014, at 4:55 PM, Colin Perkins <csp@csperkins.org> wrote:
 
 Without having seen the submitted version, this sounds okay.
 
 -- 
 Colin Perkins
 http://csperkins.org/
 
 
 
 On 29 Aug 2014, at 21:16, Ben Campbell <ben@nostrum.com> wrote:
 
 Thanks, David!
 
 Am I counting correctly that this would close the last substantive open issue? If so, and if Harald and Colin confirm they are okay with the change, we should be able to request publication for the upcoming version, correct?
 
 (I see that Harald expressed support as I am typing this...)
 
 Thanks!
 
 Ben.
 
 On Aug 29, 2014, at 3:09 PM, Black, David <david.black@emc.com> wrote:
 
 Ok, I see a range of views from skepticism to outright opposition ...
 
 I'll delete the paragraph and reference to
the multi-stream optimization
 draft and submit the resulting -06 version w/a change note that any interaction
 of DiffServ and RTCP multi-stream optimization will be dealt with in the draft
 about the latter.
 
 That submission won't happen tonight, as the network in the SAS Lounge in
 EWR isn't even close to what we're used to at IETF meetings :-).
 
 Thanks,
 --David
 
 -----Original Message-----
 From: Harald Alvestrand [mailto:harald@alvestrand.no]
 Sent: Friday, August 29, 2014 3:29 PM
 To: Colin Perkins
 Cc: Ben Campbell; Black, David; dart@ietf.org
 Subject: Re: [Dart] draft-dart-dscp-rtp - way forward
 
 On 08/29/2014 06:04 PM, Colin Perkins wrote:
 On 29 Aug 2014, at 16:52, Harald Alvestrand <harald@alvestrand.no> wrote:
 On 08/29/2014 05:14 PM, Black, David wrote:
 Harald,
 
 I'm about to submit a -05 with the indication that the single DSCP
 recommendation for SCTP and DCCP may be revised.  The RTCP multi-stream
 optimisation text will still be in there with Colin's clarification about
 "received" streams.  I'm about to vanish for about 3 weeks, but could put in a
 revised -06 over the weekend if you can quickly convince Colin.
 Explicitly pinging Colin - Colin, are you arguing that the sentence
 
 RTCP multi-stream reporting optimizations for an RTP session
 [I-D.ietf-avtcore-rtp-multi-stream-optimisation] assume that the RTP
 streams involved experience the same packet loss behavior.  This
 mechanism is highly inappropriate when the RTP streams involved use
 different PHBs, even if those PHBs differ solely in drop precedence.
 
 should stay in the draft?
 I was, but thinking again, I'm not so sure.
 
 I think this recommendation is wrong.
 
 I can't find anything in your latest messages that speak to this particular
 point.
 You're one of the authors of -multi-stream, so you should be able to speak
 clearly to the point.
 
 Can you clarify?
 If I have several SSRCs, and receive several media streams, then provided
 each of my SSRCs sees the exact same quality for each received stream, then  I
 can use the multi-stream-optimisation to reduce the number of RTCP cross
 reports I send. The multi-stream-optimisation draft says that already, and
 it's not clear that the DART drafts needs to say anything further on the
 topic.
 
 Whether I use the same DSCP for all RTCP reports I send is, I think,
 orthogonal to whether I use the multi-stream-optimisation. The dart draft
 should possibly say that, but I'm not sure that's the sentence we have above.
 I read the sentence above as saying flatly and unconditionally "don't
 use multi-stream-optimization when the RTP streams have different PHBs"
 - which means that if I want to use one PHB for audio and another PHB
 for video, I can't use multi-stream-optimization.
 
 I'd be sad if that was the case, *especially* if we can't figure out any
 reason to make that recommendation.
 
 

 Dart mailing list
 Dart@ietf.org
 https://www.ietf.org/mailman/listinfo/dart



--
Sent from my Android device with K-9 Mail. Please excuse my brevity. ------8B8INSR2OAD19YE3272JSYWPYO2VKW-- From nobody Mon Sep 1 04:23:12 2014 Return-Path: X-Original-To: dart@ietfa.amsl.com Delivered-To: dart@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA441A0393 for ; Mon, 1 Sep 2014 04:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.969 X-Spam-Level: X-Spam-Status: No, score=-4.969 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KY1ITMLmSa-l for ; Mon, 1 Sep 2014 04:23:07 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0A4B1A0392 for ; Mon, 1 Sep 2014 04:23:06 -0700 (PDT) Received: from maildlpprd55.lss.emc.com (maildlpprd55.lss.emc.com [10.106.48.159]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s81BMvvZ012340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Sep 2014 07:22:58 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com s81BMvvZ012340 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1409570578; bh=lW1N7aJPQqQ3aAZsRr8YMECeuaU=; h=From:To:CC:Date:Subject:Message-ID:In-Reply-To:Content-Type: Content-Transfer-Encoding:MIME-Version; b=o8vzZBGemEUx4CqBV3vF4BA+CFfFxKkkEonsbDTi67/CyqRDW2l6RBf5Arq/OCDgj 3uBs0cyWpf+2J42pXMW/dNZMhPSfVo0GHQ/lIhT/CSOeiCPyw05OoSZguiSI+1MZMf QRN7HTIPOc8KkVyRkG4VAvxQZLJFlBXVPknY+wP0= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com s81BMvvZ012340 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd55.lss.emc.com (RSA Interceptor); Mon, 1 Sep 2014 07:22:35 -0400 Received: from mxhub17.corp.emc.com (mxhub17.corp.emc.com [10.254.93.46]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s81BMiVb032597 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 1 Sep 2014 07:22:44 -0400 Received: from mx15a.corp.emc.com ([169.254.1.67]) by mxhub17.corp.emc.com ([10.254.93.46]) with mapi; Mon, 1 Sep 2014 07:22:44 -0400 From: "Black, David" To: "'csp@csperkins.org'" , "'ben@nostrum.com'" Date: Mon, 1 Sep 2014 07:22:44 -0400 Thread-Topic: [Dart] draft-dart-dscp-rtp - way forward Thread-Index: Ac/F1W1Cd3Tekm0vQhaNwfA3HX6MBAAAZ93F Message-ID: <8D3D17ACE214DC429325B2B98F3AE712077D52AB90@MX15A.corp.emc.com> In-Reply-To: <90176521-2804-4F23-908E-29827FADE1A6@csperkins.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/dart/L7j222pAKh4QKB8HI_BcyjoiWcM Cc: "'harald@alvestrand.no'" , "Black, David" , "'dart@ietf.org'" Subject: Re: [Dart] draft-dart-dscp-rtp - way forward X-BeenThere: dart@ietf.org 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: Mon, 01 Sep 2014 11:23:09 -0000 TWFrZXMgc2Vuc2UgLSBsZXQgbWUgc2VlIGlmIEkgY2FuIGZpbmQgdGltZSBmb3Igb25lIG1vcmUg ZWRpdCB0aGlzIGV2ZW5pbmcgLi4uDQoNClRoYW5rcywgLS1EYXZpZCArKytTZW50IGZyb20gQmxh Y2tiZXJyeQ0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiBDb2xpbiBQZXJr aW5zIFttYWlsdG86Y3NwQGNzcGVya2lucy5vcmddDQpTZW50OiBNb25kYXksIFNlcHRlbWJlciAw MSwgMjAxNCAwNzoxMCBBTQpUbzogQmVuIENhbXBiZWxsIDxiZW5Abm9zdHJ1bS5jb20+DQpDYzog SGFyYWxkIFR2ZWl0IEFsdmVzdHJhbmQgPGhhcmFsZEBhbHZlc3RyYW5kLm5vPjsgQmxhY2ssIERh dmlkOyBkYXJ0QGlldGYub3JnIDxkYXJ0QGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtEYXJ0XSBk cmFmdC1kYXJ0LWRzY3AtcnRwIC0gd2F5IGZvcndhcmQNCg0KQmVuLA0KDQpUaGUgZ3VpZGFuY2Ug bG9va3MgZmluZSB0byBtZSwgYnV0IHRoZSBleHBsYW5hdG9yeSB0ZXh0IGluIHRoZSBsYXN0IHBh cmFncmFwaCBvZiBTZWN0aW9uIDUuNCBpcyBwZXJoYXBzIG5vdCBxdWl0ZSByaWdodC4gVGhlIHRl eHQ6DQoNCiAgIFRoaXMgZ3VpZGFuY2UgbWF5IHJlc3VsdCBpbiBkaWZmZXJlbnQgRFNDUCBtYXJr aW5ncyBmb3IgUlRQIHN0cmVhbXMNCiAgIGFuZCBSVENQIHJlY2VpdmVyIHJlcG9ydHMgYWJvdXQg dGhvc2UgUlRQIHN0cmVhbXMuICBUaGUgcmVzdWx0aW5nDQogICB2YXJpYXRpb24gaW4gbmV0d29y ayBRb1MgdHJlYXRtZW50IGJ5IHRyYWZmaWMgZGlyZWN0aW9uIGNvdWxkIHJlc3VsdA0KICAgaW4g dW5yZXByZXNlbnRhdGl2ZSByb3VuZCB0cmlwIHRpbWUgKFJUVCkgZXN0aW1hdGVzIHRoYXQgZG9u J3QNCiAgIGNvcnJlc3BvbmQgdG8gY29uc2lzdGVudCBuZXR3b3JrIFFvUyB0cmVhdG1lbnQgaW4g Ym90aCBkaXJlY3Rpb25zLg0KICAgUlRDUCByZWNlaXZlciByZXBvcnRzIG1heSBiZSByZWxhdGl2 ZWx5IGluZnJlcXVlbnQgKGUuZy4sIG1heSBiZSBzZW50DQogICBvbmx5IG9uY2UgcGVyIHZpZGVv IGZyYW1lIHJlbmRlcmVkKSBhbmQgaGVuY2UgdGhlIHJlc3VsdGluZyBSVFQNCiAgIGVzdGltYXRl cyBhcmUgb2YgbGltaXRlZCB1dGlsaXR5IGZvciBjb25nZXN0aW9uIGNvbnRyb2wgKGFsdGhvdWdo DQogICB0aGV5IGhhdmUgb3RoZXIgaW1wb3J0YW50IHVzZXMsIHNlZSBbUkZDMzU1MF0pLiAgRm9y IHRoaXMgcmVhc29uLCBpdA0KICAgaXMgbm90IGltcG9ydGFudCB0aGF0IFJUQ1AgcmVjZWl2ZXIg cmVwb3J0cyByZWNlaXZlIHRoZSBzYW1lIG5ldHdvcmsNCiAgIFFvUyB0cmVhdG1lbnQgYXMgdGhl IFJUUCBzdHJlYW0gb3Igc3RyZWFtcyBiZWluZyByZXBvcnRlZCBvbi4NCg0Kc3VnZ2VzdHMgdGhh dCB0aGUgUlRUIGVzdGltYXRlIGRlcml2ZWQgZnJvbSBSVENQIHdpbGwgYmUgdW5yZXByZXNlbnRh dGl2ZSwgc2luY2UgaXQgbWF5IG5vdCBoYXZlIGNvbnNpc3RlbnQgbmV0d29yayBRb1MgaW4gZWFj aCBkaXJlY3Rpb24uIEhvd2V2ZXIsIHNpbmNlIHRoZSBSVFAgbWVkaWEgcGFja2V0cyBjYW4gdXNl IGRpZmZlcmVudCBRb1MgaW4gZWFjaCBkaXJlY3Rpb24sIHRoZSBSVENQIGFsc28gbmVlZHMgdG8g ZG8gc28sIHRvIGJlIHJlcHJlc2VudGF0aXZlISBJZiB0aGUgbWVkaWEgdXNlZCBkaWZmZXJlbnQg UW9TIG1hcmtpbmdzIGZvciBkaWZmZXJlbnQgZGlyZWN0aW9ucyBhbmQgdGhlIFJUQ1AgdXNlZCB0 aGUgc2FtZSBtYXJraW5nLCB0aGUgUlRUIGVzdGltYXRlIHdvdWxkbuKAmXQgbWF0Y2ggdGhhdCBv ZiB0aGUgbWVkaWEuIA0KDQpJIHN1Z2dlc3QgdGhlIHBhcmFncmFwaCBiZSBjaGFuZ2VkIHRvOg0K DQogICBUaGlzIGd1aWRhbmNlIG1heSByZXN1bHQgaW4gZGlmZmVyZW50IERTQ1AgbWFya2luZ3Mg Zm9yIFJUUCBzdHJlYW1zDQogICBhbmQgdGhlIFJUQ1AgcGFja2V0cyByZXBvcnRpbmcgb24gdGhv c2UgUlRQIHN0cmVhbXMuICBUaGUgcmVzdWx0aW5nDQogICB2YXJpYXRpb24gaW4gbmV0d29yayBR b1MgdHJlYXRtZW50IGJ5IHRyYWZmaWMgZGlyZWN0aW9uIGlzIG5lY2Vzc2FyeQ0KICAgdG8gZ2V0 IHJlcHJlc2VudGF0aXZlIHJvdW5kIHRyaXAgdGltZSAoUlRUKSBlc3RpbWF0ZXMgdGhhdCBjb3Jy ZXNwb25kIA0KICAgdG8gdGhlIG1lZGlhIHBhdGggUlRULiBSVENQIHJlY2VpdmVyIHJlcG9ydHMg bWF5IGJlIHJlbGF0aXZlbHkgaW5mcmVxdWVudCANCiAgIGFuZCBoZW5jZSB0aGUgcmVzdWx0aW5n IFJUVCBlc3RpbWF0ZXMgYXJlIG9mIGxpbWl0ZWQgdXRpbGl0eSBmb3IgY29uZ2VzdGlvbiANCiAg IGNvbnRyb2wgKGFsdGhvdWdoIHRoZXkgaGF2ZSBvdGhlciBpbXBvcnRhbnQgdXNlcywgc2VlIFtS RkMzNTUwXSkuICBGb3IgdGhpcyANCiAgIHJlYXNvbiwgaXQgaXMgaW1wb3J0YW50IHRoYXQgUlRD UCByZWNlaXZlciByZXBvcnRzIHNlbnQgYnkgYW4gU1NSQyByZWNlaXZlIA0KICAgdGhlIHNhbWUg bmV0d29yayBRb1MgdHJlYXRtZW50IGFzIHRoZSBSVFAgc3RyZWFtIGJlaW5nIHNlbnQgYnkgdGhh dCBTU1JDLg0KDQpDb2xpbg0KDQoNCg0KDQpPbiAzMSBBdWcgMjAxNCwgYXQgMDE6MjYsIEJlbiBD YW1wYmVsbCA8YmVuQG5vc3RydW0uY29tPiB3cm90ZToNCj4gQ29saW4gYW5kIEhhcmFsZCwNCj4g DQo+IEkgc2VlIERhdmlkIGhhcyBzdWJtaXR0ZWQgdmVyc2lvbiAwNi4gQ2FuIHlvdSB2ZXJpZnkg dGhhdCB5b3UgYXJlIG9rYXkgd2l0aCB0aGUgbGFuZ3VhZ2UgaW4gdGhpcyB2ZXJzaW9uPyANCj4g DQo+IFRoYW5rcyENCj4gDQo+IEJlbi4NCj4gDQo+IE9uIEF1ZyAyOSwgMjAxNCwgYXQgNDo1NSBQ TSwgQ29saW4gUGVya2lucyA8Y3NwQGNzcGVya2lucy5vcmc+IHdyb3RlOg0KPiANCj4+IFdpdGhv dXQgaGF2aW5nIHNlZW4gdGhlIHN1Ym1pdHRlZCB2ZXJzaW9uLCB0aGlzIHNvdW5kcyBva2F5Lg0K Pj4gDQo+PiAtLSANCj4+IENvbGluIFBlcmtpbnMNCj4+IGh0dHA6Ly9jc3BlcmtpbnMub3JnLw0K Pj4gDQo+PiANCj4+IA0KPj4+IE9uIDI5IEF1ZyAyMDE0LCBhdCAyMToxNiwgQmVuIENhbXBiZWxs IDxiZW5Abm9zdHJ1bS5jb20+IHdyb3RlOg0KPj4+IA0KPj4+IFRoYW5rcywgRGF2aWQhDQo+Pj4g DQo+Pj4gQW0gSSBjb3VudGluZyBjb3JyZWN0bHkgdGhhdCB0aGlzIHdvdWxkIGNsb3NlIHRoZSBs YXN0IHN1YnN0YW50aXZlIG9wZW4gaXNzdWU/IElmIHNvLCBhbmQgaWYgSGFyYWxkIGFuZCBDb2xp biBjb25maXJtIHRoZXkgYXJlIG9rYXkgd2l0aCB0aGUgY2hhbmdlLCB3ZSBzaG91bGQgYmUgYWJs ZSB0byByZXF1ZXN0IHB1YmxpY2F0aW9uIGZvciB0aGUgdXBjb21pbmcgdmVyc2lvbiwgY29ycmVj dD8NCj4+PiANCj4+PiAoSSBzZWUgdGhhdCBIYXJhbGQgZXhwcmVzc2VkIHN1cHBvcnQgYXMgSSBh bSB0eXBpbmcgdGhpcy4uLikNCj4+PiANCj4+PiBUaGFua3MhDQo+Pj4gDQo+Pj4gQmVuLg0KPj4+ IA0KPj4+PiBPbiBBdWcgMjksIDIwMTQsIGF0IDM6MDkgUE0sIEJsYWNrLCBEYXZpZCA8ZGF2aWQu YmxhY2tAZW1jLmNvbT4gd3JvdGU6DQo+Pj4+IA0KPj4+PiBPaywgSSBzZWUgYSByYW5nZSBvZiB2 aWV3cyBmcm9tIHNrZXB0aWNpc20gdG8gb3V0cmlnaHQgb3Bwb3NpdGlvbiAuLi4NCj4+Pj4gDQo+ Pj4+IEknbGwgZGVsZXRlIHRoZSBwYXJhZ3JhcGggYW5kIHJlZmVyZW5jZSB0byB0aGUgbXVsdGkt c3RyZWFtIG9wdGltaXphdGlvbg0KPj4+PiBkcmFmdCBhbmQgc3VibWl0IHRoZSByZXN1bHRpbmcg LTA2IHZlcnNpb24gdy9hIGNoYW5nZSBub3RlIHRoYXQgYW55IGludGVyYWN0aW9uDQo+Pj4+IG9m IERpZmZTZXJ2IGFuZCBSVENQIG11bHRpLXN0cmVhbSBvcHRpbWl6YXRpb24gd2lsbCBiZSBkZWFs dCB3aXRoIGluIHRoZSBkcmFmdA0KPj4+PiBhYm91dCB0aGUgbGF0dGVyLg0KPj4+PiANCj4+Pj4g VGhhdCBzdWJtaXNzaW9uIHdvbid0IGhhcHBlbiB0b25pZ2h0LCBhcyB0aGUgbmV0d29yayBpbiB0 aGUgU0FTIExvdW5nZSBpbg0KPj4+PiBFV1IgaXNuJ3QgZXZlbiBjbG9zZSB0byB3aGF0IHdlJ3Jl IHVzZWQgdG8gYXQgSUVURiBtZWV0aW5ncyA6LSkuDQo+Pj4+IA0KPj4+PiBUaGFua3MsDQo+Pj4+ IC0tRGF2aWQNCj4+Pj4gDQo+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4g RnJvbTogSGFyYWxkIEFsdmVzdHJhbmQgW21haWx0bzpoYXJhbGRAYWx2ZXN0cmFuZC5ub10NCj4+ Pj4+IFNlbnQ6IEZyaWRheSwgQXVndXN0IDI5LCAyMDE0IDM6MjkgUE0NCj4+Pj4+IFRvOiBDb2xp biBQZXJraW5zDQo+Pj4+PiBDYzogQmVuIENhbXBiZWxsOyBCbGFjaywgRGF2aWQ7IGRhcnRAaWV0 Zi5vcmcNCj4+Pj4+IFN1YmplY3Q6IFJlOiBbRGFydF0gZHJhZnQtZGFydC1kc2NwLXJ0cCAtIHdh eSBmb3J3YXJkDQo+Pj4+PiANCj4+Pj4+PiBPbiAwOC8yOS8yMDE0IDA2OjA0IFBNLCBDb2xpbiBQ ZXJraW5zIHdyb3RlOg0KPj4+Pj4+PiBPbiAyOSBBdWcgMjAxNCwgYXQgMTY6NTIsIEhhcmFsZCBB bHZlc3RyYW5kIDxoYXJhbGRAYWx2ZXN0cmFuZC5ubz4gd3JvdGU6DQo+Pj4+Pj4+PiBPbiAwOC8y OS8yMDE0IDA1OjE0IFBNLCBCbGFjaywgRGF2aWQgd3JvdGU6DQo+Pj4+Pj4+PiBIYXJhbGQsDQo+ Pj4+Pj4+PiANCj4+Pj4+Pj4+IEknbSBhYm91dCB0byBzdWJtaXQgYSAtMDUgd2l0aCB0aGUgaW5k aWNhdGlvbiB0aGF0IHRoZSBzaW5nbGUgRFNDUA0KPj4+Pj4gcmVjb21tZW5kYXRpb24gZm9yIFND VFAgYW5kIERDQ1AgbWF5IGJlIHJldmlzZWQuICBUaGUgUlRDUCBtdWx0aS1zdHJlYW0NCj4+Pj4+ IG9wdGltaXNhdGlvbiB0ZXh0IHdpbGwgc3RpbGwgYmUgaW4gdGhlcmUgd2l0aCBDb2xpbidzIGNs YXJpZmljYXRpb24gYWJvdXQNCj4+Pj4+ICJyZWNlaXZlZCIgc3RyZWFtcy4gIEknbSBhYm91dCB0 byB2YW5pc2ggZm9yIGFib3V0IDMgd2Vla3MsIGJ1dCBjb3VsZCBwdXQgaW4gYQ0KPj4+Pj4gcmV2 aXNlZCAtMDYgb3ZlciB0aGUgd2Vla2VuZCBpZiB5b3UgY2FuIHF1aWNrbHkgY29udmluY2UgQ29s aW4uDQo+Pj4+Pj4+IEV4cGxpY2l0bHkgcGluZ2luZyBDb2xpbiAtIENvbGluLCBhcmUgeW91IGFy Z3VpbmcgdGhhdCB0aGUgc2VudGVuY2UNCj4+Pj4+Pj4gDQo+Pj4+Pj4+IFJUQ1AgbXVsdGktc3Ry ZWFtIHJlcG9ydGluZyBvcHRpbWl6YXRpb25zIGZvciBhbiBSVFAgc2Vzc2lvbg0KPj4+Pj4+PiBb SS1ELmlldGYtYXZ0Y29yZS1ydHAtbXVsdGktc3RyZWFtLW9wdGltaXNhdGlvbl0gYXNzdW1lIHRo YXQgdGhlIFJUUA0KPj4+Pj4+PiBzdHJlYW1zIGludm9sdmVkIGV4cGVyaWVuY2UgdGhlIHNhbWUg cGFja2V0IGxvc3MgYmVoYXZpb3IuICBUaGlzDQo+Pj4+Pj4+IG1lY2hhbmlzbSBpcyBoaWdobHkg aW5hcHByb3ByaWF0ZSB3aGVuIHRoZSBSVFAgc3RyZWFtcyBpbnZvbHZlZCB1c2UNCj4+Pj4+Pj4g ZGlmZmVyZW50IFBIQnMsIGV2ZW4gaWYgdGhvc2UgUEhCcyBkaWZmZXIgc29sZWx5IGluIGRyb3Ag cHJlY2VkZW5jZS4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IHNob3VsZCBzdGF5IGluIHRoZSBkcmFmdD8N Cj4+Pj4+PiBJIHdhcywgYnV0IHRoaW5raW5nIGFnYWluLCBJJ20gbm90IHNvIHN1cmUuDQo+Pj4+ Pj4gDQo+Pj4+Pj4+IEkgdGhpbmsgdGhpcyByZWNvbW1lbmRhdGlvbiBpcyB3cm9uZy4NCj4+Pj4+ Pj4gDQo+Pj4+Pj4+IEkgY2FuJ3QgZmluZCBhbnl0aGluZyBpbiB5b3VyIGxhdGVzdCBtZXNzYWdl cyB0aGF0IHNwZWFrIHRvIHRoaXMgcGFydGljdWxhcg0KPj4+Pj4gcG9pbnQuDQo+Pj4+Pj4+IFlv dSdyZSBvbmUgb2YgdGhlIGF1dGhvcnMgb2YgLW11bHRpLXN0cmVhbSwgc28geW91IHNob3VsZCBi ZSBhYmxlIHRvIHNwZWFrDQo+Pj4+PiBjbGVhcmx5IHRvIHRoZSBwb2ludC4NCj4+Pj4+Pj4gDQo+ Pj4+Pj4+IENhbiB5b3UgY2xhcmlmeT8NCj4+Pj4+PiBJZiBJIGhhdmUgc2V2ZXJhbCBTU1JDcywg YW5kIHJlY2VpdmUgc2V2ZXJhbCBtZWRpYSBzdHJlYW1zLCB0aGVuIHByb3ZpZGVkDQo+Pj4+PiBl YWNoIG9mIG15IFNTUkNzIHNlZXMgdGhlIGV4YWN0IHNhbWUgcXVhbGl0eSBmb3IgZWFjaCByZWNl aXZlZCBzdHJlYW0sIHRoZW4gIEkNCj4+Pj4+IGNhbiB1c2UgdGhlIG11bHRpLXN0cmVhbS1vcHRp bWlzYXRpb24gdG8gcmVkdWNlIHRoZSBudW1iZXIgb2YgUlRDUCBjcm9zcw0KPj4+Pj4gcmVwb3J0 cyBJIHNlbmQuIFRoZSBtdWx0aS1zdHJlYW0tb3B0aW1pc2F0aW9uIGRyYWZ0IHNheXMgdGhhdCBh bHJlYWR5LCBhbmQNCj4+Pj4+IGl0J3Mgbm90IGNsZWFyIHRoYXQgdGhlIERBUlQgZHJhZnRzIG5l ZWRzIHRvIHNheSBhbnl0aGluZyBmdXJ0aGVyIG9uIHRoZQ0KPj4+Pj4gdG9waWMuDQo+Pj4+Pj4g DQo+Pj4+Pj4gV2hldGhlciBJIHVzZSB0aGUgc2FtZSBEU0NQIGZvciBhbGwgUlRDUCByZXBvcnRz IEkgc2VuZCBpcywgSSB0aGluaywNCj4+Pj4+IG9ydGhvZ29uYWwgdG8gd2hldGhlciBJIHVzZSB0 aGUgbXVsdGktc3RyZWFtLW9wdGltaXNhdGlvbi4gVGhlIGRhcnQgZHJhZnQNCj4+Pj4+IHNob3Vs ZCBwb3NzaWJseSBzYXkgdGhhdCwgYnV0IEknbSBub3Qgc3VyZSB0aGF0J3MgdGhlIHNlbnRlbmNl IHdlIGhhdmUgYWJvdmUuDQo+Pj4+PiBJIHJlYWQgdGhlIHNlbnRlbmNlIGFib3ZlIGFzIHNheWlu ZyBmbGF0bHkgYW5kIHVuY29uZGl0aW9uYWxseSAiZG9uJ3QNCj4+Pj4+IHVzZSBtdWx0aS1zdHJl YW0tb3B0aW1pemF0aW9uIHdoZW4gdGhlIFJUUCBzdHJlYW1zIGhhdmUgZGlmZmVyZW50IFBIQnMi DQo+Pj4+PiAtIHdoaWNoIG1lYW5zIHRoYXQgaWYgSSB3YW50IHRvIHVzZSBvbmUgUEhCIGZvciBh dWRpbyBhbmQgYW5vdGhlciBQSEINCj4+Pj4+IGZvciB2aWRlbywgSSBjYW4ndCB1c2UgbXVsdGkt c3RyZWFtLW9wdGltaXphdGlvbi4NCj4+Pj4+IA0KPj4+Pj4gSSdkIGJlIHNhZCBpZiB0aGF0IHdh cyB0aGUgY2FzZSwgKmVzcGVjaWFsbHkqIGlmIHdlIGNhbid0IGZpZ3VyZSBvdXQgYW55DQo+Pj4+ PiByZWFzb24gdG8gbWFrZSB0aGF0IHJlY29tbWVuZGF0aW9uLg0KPj4+IA0KPj4gDQo+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gRGFydCBtYWls aW5nIGxpc3QNCj4+IERhcnRAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vZGFydA0KPiANCg0KDQoNCi0tIA0KQ29saW4gUGVya2lucw0KaHR0cDovL2Nz cGVya2lucy5vcmcvDQoNCg0KDQo= From nobody Mon Sep 1 08:49:35 2014 Return-Path: X-Original-To: dart@ietfa.amsl.com Delivered-To: dart@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 701BC1A0277 for ; Mon, 1 Sep 2014 08:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9od-bC9v0gV for ; Mon, 1 Sep 2014 08:49:29 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27F491A02DA for ; Mon, 1 Sep 2014 08:35:09 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s81FYYDV043865 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 1 Sep 2014 10:34:37 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712077D52AB90@MX15A.corp.emc.com> Date: Mon, 1 Sep 2014 10:34:33 -0500 X-Mao-Original-Outgoing-Id: 431278473.912336-34a282b147591d5e1c9f43a4253c5a67 Content-Transfer-Encoding: quoted-printable Message-Id: <84787AE3-19F6-4C98-A6AE-DE536A5E57DE@nostrum.com> References: <8D3D17ACE214DC429325B2B98F3AE712077D52AB90@MX15A.corp.emc.com> To: "Black, David" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dart/xSD7B7H6r9FhChndE7ni8eYPwdo Cc: Harald Tveit Alvestrand , "dart@ietf.org" , "csp@csperkins.org" Subject: Re: [Dart] draft-dart-dscp-rtp - way forward X-BeenThere: dart@ietf.org 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: Mon, 01 Sep 2014 15:49:34 -0000 I already requested publication on 06, so please hold off on submitting = a new version for the moment. I want to coordinate any updates with = Richard. I think this is something we can update in any new revision from his AD = review, or as part of the IETF last call. On Sep 1, 2014, at 6:22 AM, Black, David wrote: > Makes sense - let me see if I can find time for one more edit this = evening ... >=20 > Thanks, --David +++Sent from Blackberry >=20 > ----- Original Message ----- > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: Monday, September 01, 2014 07:10 AM > To: Ben Campbell > Cc: Harald Tveit Alvestrand ; Black, David; = dart@ietf.org > Subject: Re: [Dart] draft-dart-dscp-rtp - way forward >=20 > Ben, >=20 > The guidance looks fine to me, but the explanatory text in the last = paragraph of Section 5.4 is perhaps not quite right. The text: >=20 > This guidance may result in different DSCP markings for RTP streams > and RTCP receiver reports about those RTP streams. The resulting > variation in network QoS treatment by traffic direction could result > in unrepresentative round trip time (RTT) estimates that don't > correspond to consistent network QoS treatment in both directions. > RTCP receiver reports may be relatively infrequent (e.g., may be = sent > only once per video frame rendered) and hence the resulting RTT > estimates are of limited utility for congestion control (although > they have other important uses, see [RFC3550]). For this reason, it > is not important that RTCP receiver reports receive the same network > QoS treatment as the RTP stream or streams being reported on. >=20 > suggests that the RTT estimate derived from RTCP will be = unrepresentative, since it may not have consistent network QoS in each = direction. However, since the RTP media packets can use different QoS in = each direction, the RTCP also needs to do so, to be representative! If = the media used different QoS markings for different directions and the = RTCP used the same marking, the RTT estimate wouldn=92t match that of = the media.=20 >=20 > I suggest the paragraph be changed to: >=20 > This guidance may result in different DSCP markings for RTP streams > and the RTCP packets reporting on those RTP streams. The resulting > variation in network QoS treatment by traffic direction is necessary > to get representative round trip time (RTT) estimates that = correspond=20 > to the media path RTT. RTCP receiver reports may be relatively = infrequent=20 > and hence the resulting RTT estimates are of limited utility for = congestion=20 > control (although they have other important uses, see [RFC3550]). = For this=20 > reason, it is important that RTCP receiver reports sent by an SSRC = receive=20 > the same network QoS treatment as the RTP stream being sent by that = SSRC. >=20 > Colin >=20 >=20 >=20 >=20 > On 31 Aug 2014, at 01:26, Ben Campbell wrote: >> Colin and Harald, >>=20 >> I see David has submitted version 06. Can you verify that you are = okay with the language in this version?=20 >>=20 >> Thanks! >>=20 >> Ben. >>=20 >> On Aug 29, 2014, at 4:55 PM, Colin Perkins wrote: >>=20 >>> Without having seen the submitted version, this sounds okay. >>>=20 >>> --=20 >>> Colin Perkins >>> http://csperkins.org/ >>>=20 >>>=20 >>>=20 >>>> On 29 Aug 2014, at 21:16, Ben Campbell wrote: >>>>=20 >>>> Thanks, David! >>>>=20 >>>> Am I counting correctly that this would close the last substantive = open issue? If so, and if Harald and Colin confirm they are okay with = the change, we should be able to request publication for the upcoming = version, correct? >>>>=20 >>>> (I see that Harald expressed support as I am typing this...) >>>>=20 >>>> Thanks! >>>>=20 >>>> Ben. >>>>=20 >>>>> On Aug 29, 2014, at 3:09 PM, Black, David = wrote: >>>>>=20 >>>>> Ok, I see a range of views from skepticism to outright opposition = ... >>>>>=20 >>>>> I'll delete the paragraph and reference to the multi-stream = optimization >>>>> draft and submit the resulting -06 version w/a change note that = any interaction >>>>> of DiffServ and RTCP multi-stream optimization will be dealt with = in the draft >>>>> about the latter. >>>>>=20 >>>>> That submission won't happen tonight, as the network in the SAS = Lounge in >>>>> EWR isn't even close to what we're used to at IETF meetings :-). >>>>>=20 >>>>> Thanks, >>>>> --David >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Harald Alvestrand [mailto:harald@alvestrand.no] >>>>>> Sent: Friday, August 29, 2014 3:29 PM >>>>>> To: Colin Perkins >>>>>> Cc: Ben Campbell; Black, David; dart@ietf.org >>>>>> Subject: Re: [Dart] draft-dart-dscp-rtp - way forward >>>>>>=20 >>>>>>> On 08/29/2014 06:04 PM, Colin Perkins wrote: >>>>>>>> On 29 Aug 2014, at 16:52, Harald Alvestrand = wrote: >>>>>>>>> On 08/29/2014 05:14 PM, Black, David wrote: >>>>>>>>> Harald, >>>>>>>>>=20 >>>>>>>>> I'm about to submit a -05 with the indication that the single = DSCP >>>>>> recommendation for SCTP and DCCP may be revised. The RTCP = multi-stream >>>>>> optimisation text will still be in there with Colin's = clarification about >>>>>> "received" streams. I'm about to vanish for about 3 weeks, but = could put in a >>>>>> revised -06 over the weekend if you can quickly convince Colin. >>>>>>>> Explicitly pinging Colin - Colin, are you arguing that the = sentence >>>>>>>>=20 >>>>>>>> RTCP multi-stream reporting optimizations for an RTP session >>>>>>>> [I-D.ietf-avtcore-rtp-multi-stream-optimisation] assume that = the RTP >>>>>>>> streams involved experience the same packet loss behavior. = This >>>>>>>> mechanism is highly inappropriate when the RTP streams involved = use >>>>>>>> different PHBs, even if those PHBs differ solely in drop = precedence. >>>>>>>>=20 >>>>>>>> should stay in the draft? >>>>>>> I was, but thinking again, I'm not so sure. >>>>>>>=20 >>>>>>>> I think this recommendation is wrong. >>>>>>>>=20 >>>>>>>> I can't find anything in your latest messages that speak to = this particular >>>>>> point. >>>>>>>> You're one of the authors of -multi-stream, so you should be = able to speak >>>>>> clearly to the point. >>>>>>>>=20 >>>>>>>> Can you clarify? >>>>>>> If I have several SSRCs, and receive several media streams, then = provided >>>>>> each of my SSRCs sees the exact same quality for each received = stream, then I >>>>>> can use the multi-stream-optimisation to reduce the number of = RTCP cross >>>>>> reports I send. The multi-stream-optimisation draft says that = already, and >>>>>> it's not clear that the DART drafts needs to say anything further = on the >>>>>> topic. >>>>>>>=20 >>>>>>> Whether I use the same DSCP for all RTCP reports I send is, I = think, >>>>>> orthogonal to whether I use the multi-stream-optimisation. The = dart draft >>>>>> should possibly say that, but I'm not sure that's the sentence we = have above. >>>>>> I read the sentence above as saying flatly and unconditionally = "don't >>>>>> use multi-stream-optimization when the RTP streams have different = PHBs" >>>>>> - which means that if I want to use one PHB for audio and another = PHB >>>>>> for video, I can't use multi-stream-optimization. >>>>>>=20 >>>>>> I'd be sad if that was the case, *especially* if we can't figure = out any >>>>>> reason to make that recommendation. >>>>=20 >>>=20 >>> _______________________________________________ >>> Dart mailing list >>> Dart@ietf.org >>> https://www.ietf.org/mailman/listinfo/dart >>=20 >=20 >=20 >=20 > --=20 > Colin Perkins > http://csperkins.org/ >=20 >=20 >=20 From nobody Sat Sep 13 05:21:56 2014 Return-Path: X-Original-To: dart@ietfa.amsl.com Delivered-To: dart@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63F871A885F for ; Sat, 13 Sep 2014 05:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.852 X-Spam-Level: X-Spam-Status: No, score=-0.852 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9UrYzMg2nlZQ for ; Sat, 13 Sep 2014 05:21:46 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 5146B1A8848 for ; Sat, 13 Sep 2014 05:21:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 8FE3A7C422D for ; Sat, 13 Sep 2014 14:21:43 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXcHQXPoAle9 for ; Sat, 13 Sep 2014 14:21:43 +0200 (CEST) Received: from [195.69.50.94] (unknown [195.69.50.94]) by mork.alvestrand.no (Postfix) with ESMTPSA id 004BD7C422C for ; Sat, 13 Sep 2014 14:21:42 +0200 (CEST) Message-ID: <54141230.5070507@alvestrand.no> Date: Sat, 13 Sep 2014 02:45:20 -0700 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: "dart@ietf.org" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dart/mPpp8d4gGv09sWtgiMk4uihhscU Subject: [Dart] I have reviewed dart -06 X-BeenThere: dart@ietf.org 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: Sat, 13 Sep 2014 12:21:49 -0000 and I'm happy with the document as it currently stands. Thanks for all the hard work! -- Surveillance is pervasive. Go Dark. From nobody Tue Sep 23 19:21:46 2014 Return-Path: X-Original-To: dart@ietfa.amsl.com Delivered-To: dart@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E01221A8A3B for ; Tue, 23 Sep 2014 19:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.577 X-Spam-Level: X-Spam-Status: No, score=-0.577 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnYL9WnJXVoE for ; Tue, 23 Sep 2014 19:21:42 -0700 (PDT) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB7981A8A3A for ; Tue, 23 Sep 2014 19:21:41 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id w7so4148550lbi.20 for ; Tue, 23 Sep 2014 19:21:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=PgqCjQhxLiXf9Q8zSp+VE4JBL5qZ5FxpZTxeq2rYFQA=; b=kGL/IVtKY1UgMmUA36r21sfXP4uLd0g4iWkipjyXqGvaARJxCqaZA4LZFELb7oEnET bXvU541gPpma6iXbaUEOWEsZcK/XpQPL1/X1Jl7mDfijm0Gz0TKKVLuKWe5zSsQraL3c adD/xvSLhSVyNqLMmt2sccuDK4MOh6NNlq2WIPZU5GhErPGTOyw7MP7vqStKvuC3uugU o8zLVNs6ZUHfzw7boD8bgnl2pqG+T9Gq7UUfgd6K73xqCJObHpJjtDoQN6BNCl9VBbcM nydl90iujzpjlkna01K/xgHapvsoY/4rclHtqJEFbGjSBpvTtMm6WaE6CuSIrQS7QXpa OoDA== X-Gm-Message-State: ALoCoQlk8B76BqR5JBa7U6ziiJOXjFTZpK0BLppoheWJm0M65GmXBIysWgDTRNWee8pijL14OKrK MIME-Version: 1.0 X-Received: by 10.152.243.34 with SMTP id wv2mr3207601lac.45.1411525299692; Tue, 23 Sep 2014 19:21:39 -0700 (PDT) Received: by 10.25.142.3 with HTTP; Tue, 23 Sep 2014 19:21:39 -0700 (PDT) Date: Tue, 23 Sep 2014 22:21:39 -0400 Message-ID: From: Richard Barnes To: draft-ietf-dart-dscp-rtp@tools.ietf.org, dart@ietf.org Content-Type: multipart/alternative; boundary=001a113434081478e70503c65854 Archived-At: http://mailarchive.ietf.org/arch/msg/dart/5RGR-oGmjFSQhzXy5lWiIYyvVLs Subject: [Dart] AD review of draft-ietf-dart-dscp-rtp-06 X-BeenThere: dart@ietf.org 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: Wed, 24 Sep 2014 02:21:44 -0000 --001a113434081478e70503c65854 Content-Type: text/plain; charset=UTF-8 I have reviewed this draft in preparation for IETF LC. Overall this looks very good. As someone who is not deeply familiar with DiffServ concepts, the document provided a helpful introduction and clearly justified its recommendations. I'll go ahead and request last call. Some minor comments are below. My main concern is that this document is so well populated with references that it will get stuck in MISSREF for years while others catch up :) Thanks, --Richard MINOR Section 6: """ The only use of multiple standardized PHBs and DSCPs that prevents network reordering among packets marked with different DSCPs is use of PHBs within a single AF class. """ It doesn't prevent reordering, right? It just makes reordering much more unlikely and more transient. (Unless you're using a strict definition of "network reordering" that ignores things like ECMP balancing.) The "allow" phrasing is used several times in this section. It would be helpful to clarify. EDITORIAL Abstract: """ Use of different DSCPs to obtain different QoS treatments within a single network 5-tuple, the results (e.g., reordering) may cause transport protocol interactions, particularly with congestion control functionality. """ This sentence doesn't really parse. Maybe just delete "the results (e.g., reordering)"? Likewise for the same phrase in the introduction. Introduction: """ (Section 7 is an empty IANA Considerations section) """ Note to future self: Remove this parenthetical and renumber once this hits the RFC Editor. Section 5.1: """ In general, marking packets with different DSCPs results in different PHBs being applied at nodes in the network, making reordering possible due to use of different pools of forwarding resources for each PHB. """ This seems like a pretty import, so I would state it more strongly. It doesn't just make reordering possible, it makes it much more likely. (This is the flip side of the Section 6 comment above.) --001a113434081478e70503c65854 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have reviewed this draft in preparation for IE= TF LC.=C2=A0 Overall this looks very good.=C2=A0 As someone who is not deep= ly familiar with DiffServ concepts, the document provided a helpful introdu= ction and clearly justified its recommendations.=C2=A0 I'll go ahead an= d request last call.

Some minor comments are below.=C2=A0= My main concern is that this document is so well populated with references= that it will get stuck in MISSREF for years while others catch up :)
Thanks,
--Richard


MINOR

Section 6:
"""
=C2=A0=C2=A0 The o= nly use of multiple standardized PHBs and DSCPs that prevents
=C2=A0=C2= =A0 network reordering among packets marked with different DSCPs is use
= =C2=A0=C2=A0 of PHBs within a single AF class.
"""
It doesn't prevent reordering, right?=C2=A0 It just makes reordering= much more unlikely and more transient.=C2=A0 (Unless you're using a st= rict definition of "network reordering" that ignores things like = ECMP balancing.)=C2=A0 The "allow" phrasing is used several times= in this section.=C2=A0 It would be helpful to clarify.



EDITORIAL

Abstract:
"""
=C2=A0=C2= =A0 Use of different DSCPs
=C2=A0=C2=A0 to obtain different QoS treatmen= ts within a single network 5-tuple,
=C2=A0=C2=A0 the results (e.g., reor= dering) may cause transport protocol
=C2=A0=C2=A0 interactions, particul= arly with congestion control functionality.
"""
=
This sentence doesn't really parse.=C2=A0 Maybe just delete "= the results (e.g., reordering)"?=C2=A0 Likewise for the same phrase in= the introduction.

Introduction:
"&quo= t;"
=C2=A0=C2=A0 (Section 7 is an empty IANA Considerations section= )
"""
Note to future self: Remove this pare= nthetical and renumber once this hits the RFC Editor.

Sec= tion 5.1:
"""
=C2=A0=C2=A0 In general, marking packets= with different DSCPs results in different
=C2=A0=C2=A0 PHBs being appli= ed at nodes in the network, making reordering
=C2=A0=C2=A0 possible due = to use of different pools of forwarding resources for
=C2=A0=C2=A0 each = PHB.
"""
This seems like a pretty import, s= o I would state it more strongly.=C2=A0 It doesn't just make reordering= possible, it makes it much more likely.=C2=A0 (This is the flip side of th= e Section 6 comment above.)





--001a113434081478e70503c65854-- From nobody Wed Sep 24 06:11:20 2014 Return-Path: X-Original-To: dart@ietfa.amsl.com Delivered-To: dart@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA891A00D0 for ; Wed, 24 Sep 2014 06:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.086 X-Spam-Level: X-Spam-Status: No, score=-5.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a6dfwTeez8ZU for ; Wed, 24 Sep 2014 06:11:14 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1C041A00D1 for ; Wed, 24 Sep 2014 06:11:13 -0700 (PDT) Received: from maildlpprd02.lss.emc.com (maildlpprd02.lss.emc.com [10.253.24.34]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s8ODBBWf030234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Sep 2014 09:11:11 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com s8ODBBWf030234 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1411564271; bh=4Br+M2TCJ3U9c3IKXlujVLl8XJQ=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=U32aQzbFKqAiujMn6MNiyuIM0uUJRyUNPcqf7aMOYY5PVD1sY5DrrkBi/Imfd8Tjz CGorWj1S3URkZOy8l2bT0Zg91UCL/iuKspZhC2yoTK469YOJ8YnLaZtgZcAt1Ymnjn 8OFYf+2ccbACPZH4ZLNQUFbDDCQL1TMDVcedd5j0= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com s8ODBBWf030234 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd02.lss.emc.com (RSA Interceptor); Wed, 24 Sep 2014 09:10:43 -0400 Received: from mxhub04.corp.emc.com (mxhub04.corp.emc.com [10.254.141.106]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s8ODApfO027977 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Sep 2014 09:10:52 -0400 Received: from mx15a.corp.emc.com ([169.254.1.67]) by mxhub04.corp.emc.com ([10.254.141.106]) with mapi; Wed, 24 Sep 2014 09:10:51 -0400 From: "Black, David" To: Richard Barnes , "dart@ietf.org" Date: Wed, 24 Sep 2014 09:10:50 -0400 Thread-Topic: [Dart] AD review of draft-ietf-dart-dscp-rtp-06 Thread-Index: Ac/Xnk+srrg/DWDDR8+KDhy2wVBldgAWJbqg Message-ID: <8D3D17ACE214DC429325B2B98F3AE712077D725B83@MX15A.corp.emc.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8D3D17ACE214DC429325B2B98F3AE712077D725B83MX15Acorpemcc_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/dart/3chrAN84RmWQ5gYL0PS1krSeyyk Subject: Re: [Dart] AD review of draft-ietf-dart-dscp-rtp-06 X-BeenThere: dart@ietf.org 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: Wed, 24 Sep 2014 13:11:18 -0000 --_000_8D3D17ACE214DC429325B2B98F3AE712077D725B83MX15Acorpemcc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmljaGFyZCwNCg0KVGhhbmsgeW91IGZvciB0aGUgcmV2aWV3LCBhbmQgSeKAmW0gcGxlYXNlZCB0 aGF0IHRoZSBkcmFmdCBwcm92aWRlcyBhIGhlbHBmdWwgaW50cm9kdWN0aW9uIHRvIERpZmZTZXJ2 Lg0KDQpDb21tZW50cyBpbmxpbmUgQCBEYXZpZD4NCg0KSeKAmWxsIHN1Ym1pdCBhIC0wNyB3aXRo IHRoZXNlIGNoYW5nZXMgcGx1cyBhIHZlcnNpb24gb2YgQ29saW7igJlzIHN1Z2dlc3RlZCBjaGFu Z2UgdG8gdGhlIDUuNCB0ZXh0IG9uIFJUQ1AgUlRUIGJlaGF2aW9yLg0KDQpUaGFua3MsDQotLURh dmlkDQoNCkZyb206IERhcnQgW21haWx0bzpkYXJ0LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBSaWNoYXJkIEJhcm5lcw0KU2VudDogVHVlc2RheSwgU2VwdGVtYmVyIDIzLCAyMDE0IDEw OjIyIFBNDQpUbzogZHJhZnQtaWV0Zi1kYXJ0LWRzY3AtcnRwQHRvb2xzLmlldGYub3JnOyBkYXJ0 QGlldGYub3JnDQpTdWJqZWN0OiBbRGFydF0gQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtZGFydC1k c2NwLXJ0cC0wNg0KDQpJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkcmFmdCBpbiBwcmVwYXJhdGlvbiBm b3IgSUVURiBMQy4gIE92ZXJhbGwgdGhpcyBsb29rcyB2ZXJ5IGdvb2QuICBBcyBzb21lb25lIHdo byBpcyBub3QgZGVlcGx5IGZhbWlsaWFyIHdpdGggRGlmZlNlcnYgY29uY2VwdHMsIHRoZSBkb2N1 bWVudCBwcm92aWRlZCBhIGhlbHBmdWwgaW50cm9kdWN0aW9uIGFuZCBjbGVhcmx5IGp1c3RpZmll ZCBpdHMgcmVjb21tZW5kYXRpb25zLiAgSSdsbCBnbyBhaGVhZCBhbmQgcmVxdWVzdCBsYXN0IGNh bGwuDQpTb21lIG1pbm9yIGNvbW1lbnRzIGFyZSBiZWxvdy4gIE15IG1haW4gY29uY2VybiBpcyB0 aGF0IHRoaXMgZG9jdW1lbnQgaXMgc28gd2VsbCBwb3B1bGF0ZWQgd2l0aCByZWZlcmVuY2VzIHRo YXQgaXQgd2lsbCBnZXQgc3R1Y2sgaW4gTUlTU1JFRiBmb3IgeWVhcnMgd2hpbGUgb3RoZXJzIGNh dGNoIHVwIDopDQoNClRoYW5rcywNCi0tUmljaGFyZA0KDQpNSU5PUg0KDQpTZWN0aW9uIDY6DQoi IiINCiAgIFRoZSBvbmx5IHVzZSBvZiBtdWx0aXBsZSBzdGFuZGFyZGl6ZWQgUEhCcyBhbmQgRFND UHMgdGhhdCBwcmV2ZW50cw0KICAgbmV0d29yayByZW9yZGVyaW5nIGFtb25nIHBhY2tldHMgbWFy a2VkIHdpdGggZGlmZmVyZW50IERTQ1BzIGlzIHVzZQ0KICAgb2YgUEhCcyB3aXRoaW4gYSBzaW5n bGUgQUYgY2xhc3MuDQoiIiINCkl0IGRvZXNuJ3QgcHJldmVudCByZW9yZGVyaW5nLCByaWdodD8g IEl0IGp1c3QgbWFrZXMgcmVvcmRlcmluZyBtdWNoIG1vcmUgdW5saWtlbHkgYW5kIG1vcmUgdHJh bnNpZW50LiAgKFVubGVzcyB5b3UncmUgdXNpbmcgYSBzdHJpY3QgZGVmaW5pdGlvbiBvZiAibmV0 d29yayByZW9yZGVyaW5nIiB0aGF0IGlnbm9yZXMgdGhpbmdzIGxpa2UgRUNNUCBiYWxhbmNpbmcu KSAgVGhlICJhbGxvdyIgcGhyYXNpbmcgaXMgdXNlZCBzZXZlcmFsIHRpbWVzIGluIHRoaXMgc2Vj dGlvbi4gIEl0IHdvdWxkIGJlIGhlbHBmdWwgdG8gY2xhcmlmeS4NCg0KRGF2aWQ+IFdpbGwgY2hh bmdlIOKAnHByZXZlbnRz4oCdIC0+IOKAnGRvZXMgbm90IGVuYWJsZeKAnSBhbmQgY2hhbmdlIOKA nGFsbG934oCdIC0+IOKAnGVuYWJsZeKAnQ0KRURJVE9SSUFMDQpBYnN0cmFjdDoNCiIiIg0KICAg VXNlIG9mIGRpZmZlcmVudCBEU0NQcw0KICAgdG8gb2J0YWluIGRpZmZlcmVudCBRb1MgdHJlYXRt ZW50cyB3aXRoaW4gYSBzaW5nbGUgbmV0d29yayA1LXR1cGxlLA0KICAgdGhlIHJlc3VsdHMgKGUu Zy4sIHJlb3JkZXJpbmcpIG1heSBjYXVzZSB0cmFuc3BvcnQgcHJvdG9jb2wNCiAgIGludGVyYWN0 aW9ucywgcGFydGljdWxhcmx5IHdpdGggY29uZ2VzdGlvbiBjb250cm9sIGZ1bmN0aW9uYWxpdHku DQoiIiINClRoaXMgc2VudGVuY2UgZG9lc24ndCByZWFsbHkgcGFyc2UuICBNYXliZSBqdXN0IGRl bGV0ZSAidGhlIHJlc3VsdHMgKGUuZy4sIHJlb3JkZXJpbmcpIj8gIExpa2V3aXNlIGZvciB0aGUg c2FtZSBwaHJhc2UgaW4gdGhlIGludHJvZHVjdGlvbi4NCkRhdmlkPiBPaCBkZWFyLCBJ4oCZdmUg Y2xlYXJseSBiZWVuIHN0YXJpbmcgYXQgdGhlIHNhbWUgdGV4dCBmb3IgdG9vIGxvbmcgOi0oLiAg V2lsbCByZXBocmFzZSB0bzoNCiAgIFRoZSByZXN1bHRzIG9mIHVzaW5nIG11bHRpcGxlIERTQ1Bz DQogICB0byBvYnRhaW4gZGlmZmVyZW50IFFvUyB0cmVhdG1lbnRzIHdpdGhpbiBhIHNpbmdsZSBu ZXR3b3JrIDUtdHVwbGUgKGUuZy4sIHJlb3JkZXJpbmcpLCBoYXZlIHRyYW5zcG9ydCBwcm90b2Nv bA0KICAgaW50ZXJhY3Rpb25zLCBwYXJ0aWN1bGFybHkgd2l0aCBjb25nZXN0aW9uIGNvbnRyb2wg ZnVuY3Rpb25hbGl0eS4NCkludHJvZHVjdGlvbjoNCiIiIg0KICAgKFNlY3Rpb24gNyBpcyBhbiBl bXB0eSBJQU5BIENvbnNpZGVyYXRpb25zIHNlY3Rpb24pDQoiIiINCk5vdGUgdG8gZnV0dXJlIHNl bGY6IFJlbW92ZSB0aGlzIHBhcmVudGhldGljYWwgYW5kIHJlbnVtYmVyIG9uY2UgdGhpcyBoaXRz IHRoZSBSRkMgRWRpdG9yLg0KRGF2aWQ+IEnigJlsbCBzd2FwIHRoZSBvcmRlciBvZiBzZWN0aW9u cyA3IGFuZCA4LCB0aGVuIGRlbGV0ZSB0aGlzIHBhcmVudGhldGljYWwgcmVtYXJrIG5vdyA7LSku DQpTZWN0aW9uIDUuMToNCiIiIg0KICAgSW4gZ2VuZXJhbCwgbWFya2luZyBwYWNrZXRzIHdpdGgg ZGlmZmVyZW50IERTQ1BzIHJlc3VsdHMgaW4gZGlmZmVyZW50DQogICBQSEJzIGJlaW5nIGFwcGxp ZWQgYXQgbm9kZXMgaW4gdGhlIG5ldHdvcmssIG1ha2luZyByZW9yZGVyaW5nDQogICBwb3NzaWJs ZSBkdWUgdG8gdXNlIG9mIGRpZmZlcmVudCBwb29scyBvZiBmb3J3YXJkaW5nIHJlc291cmNlcyBm b3INCiAgIGVhY2ggUEhCLg0KIiIiDQpUaGlzIHNlZW1zIGxpa2UgYSBwcmV0dHkgaW1wb3J0LCBz byBJIHdvdWxkIHN0YXRlIGl0IG1vcmUgc3Ryb25nbHkuICBJdCBkb2Vzbid0IGp1c3QgbWFrZSBy ZW9yZGVyaW5nIHBvc3NpYmxlLCBpdCBtYWtlcyBpdCBtdWNoIG1vcmUgbGlrZWx5LiAgKFRoaXMg aXMgdGhlIGZsaXAgc2lkZSBvZiB0aGUgU2VjdGlvbiA2IGNvbW1lbnQgYWJvdmUuKQ0KRGF2aWQ+ IOKAnHBvc3NpYmxl4oCdIC0+IOKAnHZlcnkgbGlrZWx54oCdDQoNCg0KDQoNCg0K --_000_8D3D17ACE214DC429325B2B98F3AE712077D725B83MX15Acorpemcc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFj azsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7DQoJdGV4dC1kZWNv cmF0aW9uOm5vbmUgbm9uZTt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4w aW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9o ZWFkPjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdv cmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFjayc+UmljaGFyZCw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFjayc+VGhhbmsgeW91 IGZvciB0aGUgcmV2aWV3LCBhbmQgSeKAmW0gcGxlYXNlZCB0aGF0IHRoZSBkcmFmdCBwcm92aWRl cyBhIGhlbHBmdWwgaW50cm9kdWN0aW9uIHRvIERpZmZTZXJ2LjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOmJsYWNrJz5Db21tZW50cyBpbmxpbmUgQCBEYXZp ZCZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6YmxhY2sn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFj ayc+SeKAmWxsIHN1Ym1pdCBhIC0wNyB3aXRoIHRoZXNlIGNoYW5nZXMgcGx1cyBhIHZlcnNpb24g b2YgQ29saW7igJlzIHN1Z2dlc3RlZCBjaGFuZ2UgdG8gdGhlIDUuNCB0ZXh0IG9uIFJUQ1AgUlRU IGJlaGF2aW9yLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpi bGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 Y29sb3I6YmxhY2snPlRoYW5rcyw8YnI+LS1EYXZpZDwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOmJsYWNrJz48bzpwPjwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6YmxhY2snPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQnPjxkaXY+PGRpdiBz dHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21h Iiwic2Fucy1zZXJpZiInPiBEYXJ0IFttYWlsdG86ZGFydC1ib3VuY2VzQGlldGYub3JnXSA8Yj5P biBCZWhhbGYgT2YgPC9iPlJpY2hhcmQgQmFybmVzPGJyPjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBT ZXB0ZW1iZXIgMjMsIDIwMTQgMTA6MjIgUE08YnI+PGI+VG86PC9iPiBkcmFmdC1pZXRmLWRhcnQt ZHNjcC1ydHBAdG9vbHMuaWV0Zi5vcmc7IGRhcnRAaWV0Zi5vcmc8YnI+PGI+U3ViamVjdDo8L2I+ IFtEYXJ0XSBBRCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1kYXJ0LWRzY3AtcnRwLTA2PG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwv bzpwPjwvcD48ZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1i b3R0b206MTIuMHB0Jz5JIGhhdmUgcmV2aWV3ZWQgdGhpcyBkcmFmdCBpbiBwcmVwYXJhdGlvbiBm b3IgSUVURiBMQy4mbmJzcDsgT3ZlcmFsbCB0aGlzIGxvb2tzIHZlcnkgZ29vZC4mbmJzcDsgQXMg c29tZW9uZSB3aG8gaXMgbm90IGRlZXBseSBmYW1pbGlhciB3aXRoIERpZmZTZXJ2IGNvbmNlcHRz LCB0aGUgZG9jdW1lbnQgcHJvdmlkZWQgYSBoZWxwZnVsIGludHJvZHVjdGlvbiBhbmQgY2xlYXJs eSBqdXN0aWZpZWQgaXRzIHJlY29tbWVuZGF0aW9ucy4mbmJzcDsgSSdsbCBnbyBhaGVhZCBhbmQg cmVxdWVzdCBsYXN0IGNhbGwuPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+U29tZSBtaW5vciBjb21tZW50cyBhcmUgYmVsb3cuJm5ic3A7IE15IG1haW4gY29uY2Vy biBpcyB0aGF0IHRoaXMgZG9jdW1lbnQgaXMgc28gd2VsbCBwb3B1bGF0ZWQgd2l0aCByZWZlcmVu Y2VzIHRoYXQgaXQgd2lsbCBnZXQgc3R1Y2sgaW4gTUlTU1JFRiBmb3IgeWVhcnMgd2hpbGUgb3Ro ZXJzIGNhdGNoIHVwIDopPGJyPjxicj5UaGFua3MsPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz4tLVJpY2hhcmQ8 bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwv bzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5NSU5PUjxvOnA+PC9vOnA+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPlNlY3Rpb24gNjo8YnI+JnF1b3Q7JnF1b3Q7JnF1b3Q7PGJyPiZu YnNwOyZuYnNwOyBUaGUgb25seSB1c2Ugb2YgbXVsdGlwbGUgc3RhbmRhcmRpemVkIFBIQnMgYW5k IERTQ1BzIHRoYXQgcHJldmVudHM8YnI+Jm5ic3A7Jm5ic3A7IG5ldHdvcmsgcmVvcmRlcmluZyBh bW9uZyBwYWNrZXRzIG1hcmtlZCB3aXRoIGRpZmZlcmVudCBEU0NQcyBpcyB1c2U8YnI+Jm5ic3A7 Jm5ic3A7IG9mIFBIQnMgd2l0aGluIGEgc2luZ2xlIEFGIGNsYXNzLjxicj4mcXVvdDsmcXVvdDsm cXVvdDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdp bi1ib3R0b206MTIuMHB0Jz5JdCBkb2Vzbid0IHByZXZlbnQgcmVvcmRlcmluZywgcmlnaHQ/Jm5i c3A7IEl0IGp1c3QgbWFrZXMgcmVvcmRlcmluZyBtdWNoIG1vcmUgdW5saWtlbHkgYW5kIG1vcmUg dHJhbnNpZW50LiZuYnNwOyAoVW5sZXNzIHlvdSdyZSB1c2luZyBhIHN0cmljdCBkZWZpbml0aW9u IG9mICZxdW90O25ldHdvcmsgcmVvcmRlcmluZyZxdW90OyB0aGF0IGlnbm9yZXMgdGhpbmdzIGxp a2UgRUNNUCBiYWxhbmNpbmcuKSZuYnNwOyBUaGUgJnF1b3Q7YWxsb3cmcXVvdDsgcGhyYXNpbmcg aXMgdXNlZCBzZXZlcmFsIHRpbWVzIGluIHRoaXMgc2VjdGlvbi4mbmJzcDsgSXQgd291bGQgYmUg aGVscGZ1bCB0byBjbGFyaWZ5Ljxicj48YnI+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5EYXZp ZCZndDsgV2lsbCBjaGFuZ2Ug4oCccHJldmVudHPigJ0gLSZndDsg4oCcZG9lcyBub3QgZW5hYmxl 4oCdIGFuZCBjaGFuZ2Ug4oCcYWxsb3figJ0gLSZndDsg4oCcZW5hYmxl4oCdPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbTox Mi4wcHQnPkVESVRPUklBTDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5B YnN0cmFjdDo8bzpwPjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mcXVvdDsmcXVv dDsmcXVvdDs8YnI+Jm5ic3A7Jm5ic3A7IFVzZSBvZiBkaWZmZXJlbnQgRFNDUHM8YnI+Jm5ic3A7 Jm5ic3A7IHRvIG9idGFpbiBkaWZmZXJlbnQgUW9TIHRyZWF0bWVudHMgd2l0aGluIGEgc2luZ2xl IG5ldHdvcmsgNS10dXBsZSw8YnI+Jm5ic3A7Jm5ic3A7IHRoZSByZXN1bHRzIChlLmcuLCByZW9y ZGVyaW5nKSBtYXkgY2F1c2UgdHJhbnNwb3J0IHByb3RvY29sPGJyPiZuYnNwOyZuYnNwOyBpbnRl cmFjdGlvbnMsIHBhcnRpY3VsYXJseSB3aXRoIGNvbmdlc3Rpb24gY29udHJvbCBmdW5jdGlvbmFs aXR5Ljxicj4mcXVvdDsmcXVvdDsmcXVvdDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPlRoaXMgc2VudGVuY2Ug ZG9lc24ndCByZWFsbHkgcGFyc2UuJm5ic3A7IE1heWJlIGp1c3QgZGVsZXRlICZxdW90O3RoZSBy ZXN1bHRzIChlLmcuLCByZW9yZGVyaW5nKSZxdW90Oz8mbmJzcDsgTGlrZXdpc2UgZm9yIHRoZSBz YW1lIHBocmFzZSBpbiB0aGUgaW50cm9kdWN0aW9uLjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6YmxhY2snPkRhdmlkJmd0 OyBPaCBkZWFyLCBJ4oCZdmUgY2xlYXJseSBiZWVuIHN0YXJpbmcgYXQgdGhlIHNhbWUgdGV4dCBm b3IgdG9vIGxvbmcgOi0oLsKgIFdpbGwgcmVwaHJhc2UgdG86PG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPiZuYnNwOyZu YnNwOyBUaGUgcmVzdWx0cyBvZiB1c2luZyBtdWx0aXBsZSBEU0NQczxicj4mbmJzcDsmbmJzcDsg dG8gb2J0YWluIGRpZmZlcmVudCBRb1MgdHJlYXRtZW50cyB3aXRoaW4gYSBzaW5nbGUgbmV0d29y ayA1LXR1cGxlIChlLmcuLCByZW9yZGVyaW5nKSwgaGF2ZSB0cmFuc3BvcnQgcHJvdG9jb2w8YnI+ Jm5ic3A7Jm5ic3A7IGludGVyYWN0aW9ucywgcGFydGljdWxhcmx5IHdpdGggY29uZ2VzdGlvbiBj b250cm9sIGZ1bmN0aW9uYWxpdHkuPHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkludHJvZHVjdGlvbjo8bzpwPjwvbzpwPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mcXVvdDsmcXVvdDsmcXVvdDs8YnI+Jm5ic3A7 Jm5ic3A7IChTZWN0aW9uIDcgaXMgYW4gZW1wdHkgSUFOQSBDb25zaWRlcmF0aW9ucyBzZWN0aW9u KTxicj4mcXVvdDsmcXVvdDsmcXVvdDs8c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2lu LWJvdHRvbToxMi4wcHQnPk5vdGUgdG8gZnV0dXJlIHNlbGY6IFJlbW92ZSB0aGlzIHBhcmVudGhl dGljYWwgYW5kIHJlbnVtYmVyIG9uY2UgdGhpcyBoaXRzIHRoZSBSRkMgRWRpdG9yLjxvOnA+PC9v OnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29s b3I6YmxhY2snPkRhdmlkJmd0OyBJ4oCZbGwgc3dhcCB0aGUgb3JkZXIgb2Ygc2VjdGlvbnMgNyBh bmQgOCwgdGhlbiBkZWxldGUgdGhpcyBwYXJlbnRoZXRpY2FsIHJlbWFyayBub3cgOy0pLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5TZWN0aW9uIDUu MTo8YnI+JnF1b3Q7JnF1b3Q7JnF1b3Q7PGJyPiZuYnNwOyZuYnNwOyBJbiBnZW5lcmFsLCBtYXJr aW5nIHBhY2tldHMgd2l0aCBkaWZmZXJlbnQgRFNDUHMgcmVzdWx0cyBpbiBkaWZmZXJlbnQ8YnI+ Jm5ic3A7Jm5ic3A7IFBIQnMgYmVpbmcgYXBwbGllZCBhdCBub2RlcyBpbiB0aGUgbmV0d29yaywg bWFraW5nIHJlb3JkZXJpbmc8YnI+Jm5ic3A7Jm5ic3A7IHBvc3NpYmxlIGR1ZSB0byB1c2Ugb2Yg ZGlmZmVyZW50IHBvb2xzIG9mIGZvcndhcmRpbmcgcmVzb3VyY2VzIGZvcjxicj4mbmJzcDsmbmJz cDsgZWFjaCBQSEIuPGJyPiZxdW90OyZxdW90OyZxdW90OzxvOnA+PC9vOnA+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+VGhpcyBz ZWVtcyBsaWtlIGEgcHJldHR5IGltcG9ydCwgc28gSSB3b3VsZCBzdGF0ZSBpdCBtb3JlIHN0cm9u Z2x5LiZuYnNwOyBJdCBkb2Vzbid0IGp1c3QgbWFrZSByZW9yZGVyaW5nIHBvc3NpYmxlLCBpdCBt YWtlcyBpdCBtdWNoIG1vcmUgbGlrZWx5LiZuYnNwOyAoVGhpcyBpcyB0aGUgZmxpcCBzaWRlIG9m IHRoZSBTZWN0aW9uIDYgY29tbWVudCBhYm92ZS4pPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFjayc+RGF2aWQmZ3Q7 IOKAnHBvc3NpYmxl4oCdIC0mZ3Q7IOKAnHZlcnkgbGlrZWx54oCdPG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6 YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PG86cD4mbmJzcDs8L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21h cmdpbi1ib3R0b206MTIuMHB0Jz48YnI+PGJyPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjwvZGl2Pjwv ZGl2PjwvYm9keT48L2h0bWw+ --_000_8D3D17ACE214DC429325B2B98F3AE712077D725B83MX15Acorpemcc_-- From nobody Wed Sep 24 08:00:22 2014 Return-Path: X-Original-To: dart@ietfa.amsl.com Delivered-To: dart@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC8621A0140; Wed, 24 Sep 2014 08:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THpuZ9orO_Is; Wed, 24 Sep 2014 08:00:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 80B871A0115; Wed, 24 Sep 2014 08:00:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140924150013.15594.5235.idtracker@ietfa.amsl.com> Date: Wed, 24 Sep 2014 08:00:13 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dart/rJ7URczAIY4lXfOL4PPvl9Xb2f0 Cc: dart@ietf.org Subject: [Dart] I-D Action: draft-ietf-dart-dscp-rtp-07.txt X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 15:00:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DiffServ Applied to Real-time Transports Working Group of the IETF. Title : Differentiated Services (DiffServ) and Real-time Communication Authors : David Black Paul Jones Filename : draft-ietf-dart-dscp-rtp-07.txt Pages : 26 Date : 2014-09-24 Abstract: This memo 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). WebRTC applications, as well as some conferencing applications, have begun using the Session Description Protocol (SDP) bundle negotiation mechanism to send multiple traffic streams with different QoS requirements using the same network 5-tuple. The results of using multiple DSCPs to obtain different QoS treatments within a single network 5-tuple (e.g., reordering) have transport protocol interactions, particularly with congestion control functionality. In addition, DSCP markings may be changed or removed between the traffic source and destination. This memo covers the implications of these DiffServ aspects for real-time network communication, including WebRTC. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dart-dscp-rtp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dart-dscp-rtp-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dart-dscp-rtp-07 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/ From nobody Tue Sep 30 14:16:56 2014 Return-Path: X-Original-To: dart@ietfa.amsl.com Delivered-To: dart@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA1BB1A8A7D; Tue, 30 Sep 2014 13:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GrHUaNIUbgAm; Tue, 30 Sep 2014 13:58:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A6DDA1A8A51; Tue, 30 Sep 2014 13:58:10 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p2 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140930205810.16443.97645.idtracker@ietfa.amsl.com> Date: Tue, 30 Sep 2014 13:58:10 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dart/OPQpppW8Q1Ja3kGsC8yTFmfMwDA X-Mailman-Approved-At: Tue, 30 Sep 2014 14:16:54 -0700 Cc: dart@ietf.org Subject: [Dart] Last Call: (Differentiated Services (DiffServ) and Real-time Communication) to Informational RFC X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 20:58:12 -0000 The IESG has received a request from the DiffServ Applied to Real-time Transports WG (dart) to consider the following document: - 'Differentiated Services (DiffServ) and Real-time Communication' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-10-14. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This memo 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). WebRTC applications, as well as some conferencing applications, have begun using the Session Description Protocol (SDP) bundle negotiation mechanism to send multiple traffic streams with different QoS requirements using the same network 5-tuple. The results of using multiple DSCPs to obtain different QoS treatments within a single network 5-tuple (e.g., reordering) have transport protocol interactions, particularly with congestion control functionality. In addition, DSCP markings may be changed or removed between the traffic source and destination. This memo covers the implications of these DiffServ aspects for real-time network communication, including WebRTC. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dart-dscp-rtp/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dart-dscp-rtp/ballot/ No IPR declarations have been submitted directly on this I-D.