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

"Paul E. Jones" <> Mon, 09 May 2016 19:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5D20612D602; Mon, 9 May 2016 12:03:41 -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 JZCSR3Tpm6Sv; Mon, 9 May 2016 12:03:38 -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 74DFF12D5F6; Mon, 9 May 2016 12:03:11 -0700 (PDT)
Received: from [] ( [] (may be forged)) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id u49J34C6000812 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 May 2016 15:03:05 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=dublin; t=1462820586; bh=hOS+Dsr/FoVT+ouwnWQwfgLgt/X0XA/fPlZ1aHtkgso=; h=From:To:Subject:Cc:Date:In-Reply-To:Reply-To; b=JF0QCv8oOGGLnro3032dp4d8Q1Cao2LadoBh8iES1cZcnikMGBR1rF/sosIaop1u7 Ib6VTtBneQpTU1TwzyvQMjJZUHnbotKPcbyx4axMKEUvvrr6K2REB4oCGI33tb6yMU dC7r4aY7C6RrD9dXgTePIm4jK03wUglTJK8NBroA=
From: "Paul E. Jones" <>
Date: Mon, 09 May 2016 19:03:10 +0000
Message-Id: <em88678e54-c513-4d74-8bbd-ba0785d70b36@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 ( []); Mon, 09 May 2016 15:03:06 -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: Mon, 09 May 2016 19:03:41 -0000


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

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.


------ Original Message ------
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 too 
>favored what you recommend below: transport audio and video by the same 
>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 frames 
>are to receive a lower priority /
>   higher drop precedence PHB)?
>I personally prefer AF4 if audio and video are to be transported in the 
>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 statement 
>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 possible.
>[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