Re: [rtcweb] [tsvwg] Diffserv QoS for Video

"Paul E. Jones" <> Wed, 11 May 2016 03:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AD7E612D547; Tue, 10 May 2016 20:31:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.998
X-Spam-Status: No, score=-2.998 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_NONE=-0.0001, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id v302kFzzqgCM; Tue, 10 May 2016 20:31:34 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DA20412B052; Tue, 10 May 2016 20:31:33 -0700 (PDT)
Received: from [] ( [] (may be forged)) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id u4B3VPPV016696 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 May 2016 23:31:28 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=dublin; t=1462937490; bh=pqawT0ItWap7Vn1fYJhwfU3DaZA9VYQd12jCokl2Hvg=; h=From:To:Subject:Cc:Date:In-Reply-To:Reply-To; b=mZv1hjdgXwN5dEw4ktug+9H5sFTXR5Obl04L+KcGPXkN6mG6aooLqRLOoz/T6OOtx I+JQ/zkzYbKg6zPV1ZscMBSZ2chkS9CxWC7ZlL4qsG25fSA3GrsTFecOSKaRqspEaF YpXNOyjxd2P8zj6rbiiUzfs5b0OuFc1WW2XpI0Ys=
From: "Paul E. Jones" <>
To: Harald Alvestrand <>,
Date: Wed, 11 May 2016 03:31:34 +0000
Message-Id: <em3c9daedc-e3a8-4a6f-9ccf-73d52443bce6@sydney>
In-Reply-To: <>
User-Agent: eM_Client/6.0.24928.0
Mime-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.16 ( []); Tue, 10 May 2016 23:31:30 -0400 (EDT)
Archived-At: <>
Subject: Re: [rtcweb] [tsvwg] Diffserv QoS for Video
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: "Paul E. Jones" <>
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 11 May 2016 03:31:37 -0000

Yeah, that's a good point.   Let's not go down the path of re-opening a 
new round of changes that would require yet another LC and more time.


------ Original Message ------
From: "Harald Alvestrand" <>
Sent: 5/10/2016 3:35:42 AM
Subject: Re: [tsvwg] Diffserv QoS for Video

>FTR: I don't see such an agreement at all.
>On the contrary, my perception is that people want the ability to
>deliver audio with a lower loss probability and lower delay probability
>than video - it's more important to the conversation, and there are
>fewer things the recipient can do to hide the losses. If the sender
>chose to send them on separate flows, they shold have different DSCP
>I believe this is what draft-ietf-tsvwg-rtcweb-qos-15 section 5 states,
>and I believe that this is what TSVWG has declared consensus on and
>wrote in the document that passed WG last call and is currently in
>"waiting for writeup" state.
>Changing this determination would, at minimum, require reopening the WG
>Last Call.
>And I'd object.
>Den 10. mai 2016 08:56, skrev
>>  Hi Paul,
>>  I think we agree, that audio and video frames, if both are part of 
>>the same (interactive) media flow should be transported by the same 
>>PHB [PJ] or the same queue [RG]. The latter is ensured, if the same 
>>PHB is picked for audio and video. To me the text of the draft so far 
>>doesn't express that both audio and video are supposed to use an 
>>"Interactive Video..." PHB, if both are present. I'd prefer to have 
>>text with a non binding standard requirement saying
>>       However, if the application wishes to send both interactive
>>       video and audio, it is RECOMMENDED to transport audio
>>       and video packets by the same per hop behavior. For example,
>>       audio and video packets would both be marked as AF42 or
>>       AF43.
>>  I don't insist on descriptive text proposing to transport audio by an 
>>AF4 PHB offering a lower drop ratio than that used to transport video. 
>>My audio/video experts support this and I'm pretty sure, that also 
>>Cisco representatives mentioned that audio quality ranks above video 
>>quality in telepresence sessions.
>>  Regards,
>>  Ruediger
>>  -----Ursprüngliche Nachricht-----
>>  Von: Paul E. Jones []
>>  Gesendet: Montag, 9. Mai 2016 21:03
>>  An: Geib, Rüdiger
>>  Cc:;;; 
>>  Betreff: Re: AW: [tsvwg] Diffserv QoS for Video
>>  Ruediger,
>>  Perhaps an example might be helpful.  How about I add this text for 
>>illustrative purposes?
>>       To illustrate the use of the above table, let us assume the
>>       application assigns a priority of "medium" to audio and video
>>       flows.  Given that assumption, if the application wishes to send
>>       only audio then packets would be marked EF.  However, if the
>>       application wishes to send both interactive video and audio,
>>       then audio and video packets would both be marked as AF42 or
>>       AF43.  The intent is to ensure that when both audio and video
>>       are being sent together that they receive similar per-hop
>>       behavior.
>>  This doesn't get into the preference for AF42 vs. AF43. If it were 
>>me, I'd mark all audio as AF42 and only key video frames as AF42.  All 
>>predictive frames would be sent with an AF43 marking.  I might even 
>>take it a step further and classify all audio as "high".  However, 
>>I've seen a tremendous amount of debate on this before, so I'd prefer 
>>to not go too far in dictating audio markings vs. video.  I do think 
>>most people generally agree about at least ensuring the class is the 
>>same, otherwise the wildly different PHB introduces skew between A/V 
>>packet arrival, thus inflating the size of buffers managing the A/V 
>>streams.  However, we do not want to dictate that audio should be 
>>treated significantly better than audio.  For deaf users, for example, 
>>the audio really isn't important at all.  That is perhaps an extreme 
>>example, but it nonetheless highlights why we should be cautious about 
>>exactly what we normatively mandate.
>>  Paul
>>  ------ Original Message ------
>>  From:
>>  To:
>>  Cc:;;; 
>>  Sent: 5/9/2016 3:34:25 AM
>>  Subject: AW: [tsvwg] Diffserv QoS for Video
>>>  Hi Paul,
>>>  I've talked with audio/video experts of Deutsche Telekom and they 
>>>  favored what you recommend below: transport audio and video by the 
>>>  queue. Your statement below however stops there and the draft text
>>>  doesn't clarify the issue:
>>>  If there's interactive video with audio, then they both should be
>>>  marked for the same PHB which is:
>>>  - EF ?
>>>  - AF4? Like AF41 Audio, AF42 Video (AF43 in addition, if P or B 
>>>  are to receive a lower priority /
>>>    higher drop precedence PHB)?
>>>  I personally prefer AF4 if audio and video are to be transported in 
>>>  same queue.
>>>  I'd also ask for the draft text to be clear about the issue when to
>>>  mark audio by the EF PHB. My understanding after reading your 
>>>  below is: Audio marked EF if there's no video flow only.
>>>  ...
>>>  BC>Finally, why is audio not also subdivided into interactive and
>>>  BC>non-interactive? As far as I can see, both are logically 
>>>  [PJ] For WebRTC, audio alone is "interactive" in nature (which is
>>>    why it's marked EF).  However, if one is sending audio and video
>>>    it makes sense to mark them both same way to get the same PHB and
>>>    hopefully have them queued in the same buffers along the path.
>>>    Sending audio as EF and possibly having a PHB that results in
>>>    packets arriving much faster than corresponding video packets
>>>    marked as AF42 is not at all helpful for applications that have
>>>    to synchronize the audio and video flows.
>>>  ...
>>>    Paul
>>>  Regards,
>>>  Ruediger