RE: [tsvwg] Last Call: <draft-ietf-tsvwg-rtcweb-qos-15.txt> (DSCP and other packet markings for WebRTC QoS) to Proposed Standard

"Black, David" <david.black@emc.com> Sun, 03 April 2016 21:38 UTC

Return-Path: <david.black@emc.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66B6312D646; Sun, 3 Apr 2016 14:38:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.312
X-Spam-Level:
X-Spam-Status: No, score=-4.312 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emc.com
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 Xtt1liHUzoKj; Sun, 3 Apr 2016 14:38:11 -0700 (PDT)
Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (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 DC81012D5FE; Sun, 3 Apr 2016 14:38:10 -0700 (PDT)
Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u33Lc70O005347 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 3 Apr 2016 17:38:07 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com u33Lc70O005347
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1459719488; bh=Utr270PHcC+15W8uDEcsPH3ROr4=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=hKk+niErKWgZaLgkcjbxoNBmQkmnr0g5PlB5Q9FBY2NC1k2I0oz2HnBptexu4EZxh mNvCYEtNnxopnLg00HGjZKBqD1+VLA2CAoxCRCe9Qp/9DWLbdL7c1keB7a0yA7uRz6 tWbeNcRXsvL8DjWooePz9ur5Sa2nCf5KGhWPBmuY=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com u33Lc70O005347
Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd03.lss.emc.com (RSA Interceptor); Sun, 3 Apr 2016 17:36:32 -0400
Received: from MXHUB220.corp.emc.com (MXHUB220.corp.emc.com [10.253.68.90]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u33LbtK4028819 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Sun, 3 Apr 2016 17:37:56 -0400
Received: from MX104CL02.corp.emc.com ([169.254.8.70]) by MXHUB220.corp.emc.com ([10.253.68.90]) with mapi id 14.03.0266.001; Sun, 3 Apr 2016 17:37:55 -0400
From: "Black, David" <david.black@emc.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>, Cullen Jennings <fluffy@iii.ca>
Subject: RE: [tsvwg] Last Call: <draft-ietf-tsvwg-rtcweb-qos-15.txt> (DSCP and other packet markings for WebRTC QoS) to Proposed Standard
Thread-Topic: [tsvwg] Last Call: <draft-ietf-tsvwg-rtcweb-qos-15.txt> (DSCP and other packet markings for WebRTC QoS) to Proposed Standard
Thread-Index: AQHRg5nK94t/8iR5sU+B/9y+8LxFIp9nE2eAgADT/gCACkcQgIAGp9UQ
Date: Sun, 03 Apr 2016 21:37:54 +0000
Message-ID: <CE03DB3D7B45C245BCA0D243277949362E92B245@MX104CL02.corp.emc.com>
References: <20160321174750.31944.71903.idtracker@ietfa.amsl.com> <56F26AD3.3010403@ericsson.com> <5BB71158-3530-47A2-9A33-811F65B2F677@iii.ca> <56FBBBC1.5060902@ericsson.com>
In-Reply-To: <56FBBBC1.5060902@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.250.47.120]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com
X-RSA-Classifications: public
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/11kb1zNwCWy1wMnQoi8Pqa6kQGY>
Cc: "tsvwg@ietf.org" <tsvwg@ietf.org>, "draft-ietf-tsvwg-rtcweb-qos@ietf.org" <draft-ietf-tsvwg-rtcweb-qos@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "Black, David" <david.black@emc.com>, "tsvwg-chairs@ietf.org" <tsvwg-chairs@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 03 Apr 2016 21:38:12 -0000

I see a couple of Magnus's points that appear to need additional text
in the draft:

[1] Flow Type in application-facing browser API:

> >>>> o Flow Type: The browser provides this input as it knows if
> >>>> the flow is audio, interactive video with or without audio,
> >>>> non-interactive video with or without audio, or data.

[... snip ...]

> The main issue here is that to me it was not clear that "Interactive
> Video with or without audio" allows for setting these DSCP values also
> for the RTP stream containing audio also. This, I do see a need for
> clarification on.

Propose an additional sentence:
OLD
   o  Flow Type: The browser provides this input as it knows if the flow
      is audio, interactive video with or without audio, non-interactive
      video with or without audio, or data.
NEW
   o  Flow Type: The browser provides this input as it knows if the flow
      is audio, interactive video with or without audio, non-interactive
      video with or without audio, or data.  For audio that is associated
      with a video flow, the flow type of the associated video MAY
      be used instead of the associated audio type.

I hesitate to say anything stronger than "MAY" here.

[2] What does "interactive" mean in an implementation?:

> The issue is that this document is called: DSCP and other packet
> markings for WebRTC QoS. Then this document define something that is not
> immediately mappable onto what is being defined in the other WebRTC
> specifications. That is why I am raising that there need to be more
> clear coupling. If that coupling is to mostly happen in another
> document, can we at least then have a proposal on the table for that
> change to ensure that the result is understandable.

Well, this TSVWG draft is definitely not the right place for a discussion of
when a video flow is interactive or non-interactive - I hope we can agree
on that.

Beyond that, as Cullen (Jennings) is both an author of this document and
one of the chairs of the rtcweb WG, I'd suggest that he and/or the rtcweb
WG propose an appropriate location for discussion of when a video flow
is interactive or non-interactive.  This TSVWG draft would then have an
additional sentence added, e.g.,

	See [TBD] for further discussion of how to determine
	whether a video flow is interactive vs. non-interactive.

I believe that the added reference here ([TBD] above) would be normative.

Cullen?

Thanks, --David (as document  shepherd)

> -----Original Message-----
> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]
> Sent: Wednesday, March 30, 2016 7:43 AM
> To: Cullen Jennings
> Cc: ietf@ietf.org; tsvwg-chairs@ietf.org; draft-ietf-tsvwg-rtcweb-qos@ietf.org;
> tsvwg@ietf.org
> Subject: Re: [tsvwg] Last Call: <draft-ietf-tsvwg-rtcweb-qos-15.txt> (DSCP and
> other packet markings for WebRTC QoS) to Proposed Standard
> 
> Den 2016-03-23 kl. 23:46, skrev Cullen Jennings:
> >
> >> On Mar 23, 2016, at 3:07 AM, Magnus Westerlund
> >> <magnus.westerlund@ericsson.com> wrote:
> >>
> >> Hi,
> >>
> >> Below is the first round on a question, that looks like it needs to
> >> be addressed, thus I bring it into a public discussion.
> >>
> >> Den 2016-03-22 kl. 19:48, skrev Paul E. Jones:
> >>>> The other comment I have is the following:
> >>>>
> >>>> o Flow Type: The browser provides this input as it knows if
> >>>> the flow is audio, interactive video with or without audio,
> >>>> non-interactive video with or without audio, or data.
> >>>>
> >>>> Yes, a browser knows if a MediaStreamTrack's source is a live
> >>>> source, i.e. camera or microphone or a file. Which would
> >>>> indicate the difference between interactive or non. However, I
> >>>> don't understand what the Flow Type description for video
> >>>> contains "with or without audio" as the flow definitions in
> >>>> RTCWEB transport document all indicate flows as containing a
> >>>> single media type. Can you please clarify?
> >>>
> >>> This relates to the table that follows. The intent is that if a
> >>> WebRTC application is sending audio and video (e.g., a
> >>> videoconference call), then the same DSCP values might be used
> >>> for both the audio and video flows. On the other hand, if only a
> >>> video flow is sent alone (perhaps the audio source is an entirely
> >>> different device), then the browser can still use the same packet
> >>> marking.
> >>>
> >>
> >> So, I started commenting on this because, the "Flow Types" in the
> >> table are not really defined. And my interpretation was not that
> >> the audio could be given the same markings as the Video. I only
> >> interpreted it as being valid for the video flow. Thus, I think the
> >> actual "flow type" values in Table 1 needs to be better defined. To
> >> my knowledge these types are not defined in any other RTCWeb
> >> document.
> >
> > Which codec it came from make is pretty clear if it is audio or video
> > in the browser implementation. The word "flow"  has many meanings in
> > all the different contexts but it seems like section 4 is pretty
> > clear on breaking flow down into media and data types then breaking
> > media down into the various types in the table and defining them.
> >
> > Are you getting at the issue of it a audio stream that is with a
> > synchronized video stream can use the same markings as the video
> > stream ? This tries to leave the options open and let people read
> > things like  Section 4 of RFC 7657.
> 
> The main issue here is that to me it was not clear that "Interactive
> Video with or without audio" allows for setting these DSCP values also
> for the RTP stream containing audio also. This, I do see a need for
> clarification on.
> 
> The Interactive vs Non-Interactive I do have an interpretation of what
> it means. However, I fail to see how a WebRTC browser implementation is
> going to be able to make that determination, and there are no API point
> for indicating this distinction for the moment. But, I am fine to let
> that through.
> 
> >>
> >> I think what is needed is a definition list for what is meant. I
> >> can see that pointers for example into RFC 4594 may help making
> >> these definitions more compact.
> >>
> >> One thing that might be a bit tricky is actually the difference
> >> between interactive and non-interactive (streaming) usages of
> >> WebRTC RTP streams. It becomes a question if the WebRTC endpoint
> >> actually accurately can classify these differences.
> >
> > We decided at some point that if the browser is using SRTP, it is
> > assumed to be interactive and the webrtc specs point at using this.
> > If it is streamed over HTTP with something like DASH then it is non
> > interactive and browsers could use the non interactive markings but I
> > don't think any of the streaming media docs have been updated yet to
> > point that out.
> 
> I agree with that. I also think there could be a potential development
> where one could use video over RTP in a PeerConnection with a tweaked
> configuration, much more delay tolerant that could be used also for
> non-interactive delivery. But, that is just a potential future
> modification or extension.
> 
> >
> >> Yes, a live media source, like an camera or microphone can on first
> >> order be used for classification as interactive, while a file
> >> source is non-interactive. But even the first, can in the
> >> application context be non-interactive. An example would be an
> >> lecturer application. Relaxing the delay from the lecturer to the
> >> audience is likely fine, especially if one have a "raise hand"
> >> mechanism and only explicitly invites participants to ask
> >> questions. To my knowledge there are no API surface to indicate
> >> these preferences on the MediaStream or MediaStreamTrack level.
> >>
> >> I think this document have a potential valuable difference for the
> >> interactive vs non-interactive, but the rest of the current
> >> solution has difficulties to utilize this difference. From my
> >> perspective I am fine with retaining the difference, but the
> >> definition must be clear so that implementers select the right one.
> >> And likely the non-interactive will not be much utilized until
> >> additional API knobs are created.
> >
> > Agree but I think it is the WebRTC spec that needs to be clear on
> > that, not this draft.
> 
> The issue is that this document is called: DSCP and other packet
> markings for WebRTC QoS. Then this document define something that is not
> immediately mappable onto what is being defined in the other WebRTC
> specifications. That is why I am raising that there need to be more
> clear coupling. If that coupling is to mostly happen in another
> document, can we at least then have a proposal on the table for that
> change to ensure that the result is understandable.
> 
> cheers
> 
> Magnus Westerlund
> 
> ----------------------------------------------------------------------
> Services, Media and Network features, Ericsson Research EAB/TXM
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287
> Färögatan 6                 | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------