Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-04.txt

From: [email-masked]
Date: Fri, 25 Apr 2014 01:47:26 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF.

        Title           : Transports for RTCWEB
        Author          : Harald Alvestrand
	Filename        : draft-ietf-rtcweb-transports-04.txt
	Pages           : 13
	Date            : 2014-04-25

Abstract:
   This document describes the data transport protocols used by RTCWEB,
   including the protocols used for interaction with intermediate boxes
   such as firewalls, relays and NAT boxes.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-rtcweb-transports-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-transports-04

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: Harald Alvestrand <[email-masked]>
Date: Fri, 25 Apr 2014 10:50:43 +0200

For easy access, here's the changelog section:

A.4.  Changes from -03 to -04

    o  Added a section on prioritization, moved the DSCP section into it,
       and added a section on local prioritization, giving a specific
       algorithm for interpreting "priority" in local prioritization.

    o  ICE-TCP candidates was changed from MAY to MUST, in recognition of
       the sense of the room at the London IETF.

There are also some attempts at language improvements, of course, but 
those should be the main changes.

On 04/25/2014 10:47 AM, [email-masked] wrote:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Simon Perreault <[email-masked]>
Date: Fri, 25 Apr 2014 08:53:32 -0400

>       algorithm for interpreting "priority" in local prioritization.

Harald,

The new text looks good. A comment about this part:

> 			When an RTCWEB implementation has packets to send on multiple streams	
> 			that are congestion-controlled under the same congestion controller,	
> 			the RTCWEB implementation SHOULD serve the streams in a weighted	
> 			round-robin fashion, with each stream at each level of priority being	
> 			given approximately twice the transmission capacity (measured in	
> 			payload bytes) of the level below.

This looks like a QoS algorithm that might get quickly obsoleted by
better ones. We don't want to prevent innovation in this matter by
prescribing an obsolete QoS algorithm.

Suggestion: leave it up to implementations to interpret priority levels
however they want. Reword the current text so that it becomes an
*example* of what an implementation might do.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 25 Apr 2014 15:21:21 +0200

> *example* of what an implementation might do.

The problem with doing that is that it leads to completely inconsistent 
behaviour.

The reason I wrote it this way is because the bandwidth estimation 
problem breaks down into two parts:

- Telling if it's a good idea to send a packet (congestion control)
- Deciding which packet to send (prioritization)

Congestion control is an active area of research and innovation. I said 
very little about it.

Prioritization is a different matter.

What I was trying to encapsulate was:

- Higher priority means more packets get sent
- "More" has a numeric value, so behaviour is predictable (that's where 
the x2 figure came from)
- Small packet flows get more packets than large-packet flows (counting 
bytes not packets)
- Lower priority flows can't be starved completely

This text captures that. I'd like to continue to capture that.

---

From: Simon Perreault <[email-masked]>
Date: Fri, 25 Apr 2014 09:53:37 -0400

> The problem with doing that is that it leads to completely inconsistent

Understood. But is that something we should care about? I mean, if it
does not lead to application developers doing "if (chrome) ... else if
(firefox) ..." then behaviour inconsistency is of no consequence. I
can't imagine a situation where that would happen if we leave it open.

Simon

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 25 Apr 2014 16:19:52 +0200

Harald and WG,

I am catching up on the changes and improvements in the two latest
versions. I have tried to do a complete review through and match with my
previous comments.

First of all, I think the two revisions have improved a number of things.

1. Section 3.1:
   Platforms that do not give access to these interfaces will not be
   able to support a conforming RTCWEB implementation.

I am very split over this statement. We do want platforms to support per
packet DSCP markings, while at the same time we know we might not be
able to set DSCP at all for a transport flow (5-tuple). Thus, I wonder
if calling the implementations non-conformant due to the underlying
platform is a bit though.

2. Section 3.1:
   This specification does not assume that the implementation will have
   access to ICMP or raw IP.

But, to my understanding we have things that could benefit from getting
the information from ICMP, e.g. the SCTP MTU discovery mechanism. Thus,
I wonder if this statement should be changed to:

   This specification does not assume that the implementation will have
   access to ICMP or raw IP, however access to ICMP information can
   benefit the WebRTC implementation and its performance.

3. Section 3.4:
   TURN TCP candidates [RFC6062] MAY be supported.

   However, such candidates are not seen as providing any significant
   benefit.  First, use of TURN TCP would only be relevant in cases
   which both peers are required to use TCP to establish a
   PeerConnection.  Secondly, that use case is anyway supported by both
   sides establishing UDP relay candidates using TURN over TCP to
   connect to the relay server.  Thirdly, using TCP only between the
   endpoint and its relay may result in less issues with TCP in regards
   to real-time constraints, e.g. due to head of line blocking.

I think these two paragraphs should be moved to after the following
paragraph:

   ICE-TCP candidates [RFC6544] MUST be supported; this may allow
   applications to communicate to peers with public IP addresses across
   UDP-blocking firewalls without using a TURN server.

>From a discussion of WebRTC RTP or DTLS packets over TCP, it makes
better sense to first discuss the ICE TCP candidates, then discuss why
TCP candidates from TURN makes less so.

4. Section 3.4:
   If TCP connections are used, RTP framing according to [RFC4571] MUST
   be used, both for the RTP packets and for the DTLS packets used to
   carry data channels.

I think this paragraph forgets the encapsulation of the STUN messages
that ICE emits for initial path verification and nomination, as well as
for keep-alive and consent freshness.

5. section 3.4:

   NOTE IN DRAFT: This may be added.

I don't understand this note.

6. Section 3.5:

   The setup protocol for RTCWEB data channels is described in
   [I-D.jesup-rtcweb-data-protocol].

First of all, this pointer is the individual version rather than WG draft.

Secondly, I think the DCEP shall be mandated to be supported by an
WebRTC implementation in this specification, and thus become a normative
reference also.

7. Section 4:

   The RTCWEB prioritization model is that the application tells the
   RTCWEB implementation about the priority of media and data flows
   through an API.

As we have discussed before in regards to DART as well as
draft-ietf-tsvwg-rtcweb-qos has needs for clear definitions what is
meant with media and data flows here. But, reading this section it is
clear that the document itself has need for clear definitions.

A data flow appear to be the one of the SCTP streams that forms a single
data channel, as this is the level where we assign data priority.

A WebRTC media flows is a more complex beast. It is one or more RTP
packet streams (draft-ietf-avtext-grouping-taxonomy), i.e. the RTP
packets associated with an SSRC. However, due to FEC and RTP
retransmission as well as scalable codecs, there could be multiple SSRCs
that carries data associated and possibly necessary to be able to
perform media decoding. Thus, I think we are talking about the RTP
packet streams that are the result of a single MediaStreamTrack within
one RTCPeerConnection.

I would also note that Section 4.1 uses Media Stream instead of media
flow. There are need for alignment here.

8. Section 4.1:

I think this section is a good start. It clearly needs some more input.
Especially about the notes made.

In addition to the first three configurations, I think the one where one
has different transport flows per priority level for the media flows
appears to be one most likely to require mandating implementation
support. Yes this means that I also would like to mandate implementation
support for the one transport flow per media type configuration.

9. Section 4.1:

A receiving implementation MUST be able to receive media and data in
   all these configurations.

It is very unclear what "all" in the above sentence includes.

10. Section 4.2:

First of all I do wonder if this is the right solution. I haven't yet
spent enough time on the issue to know if the proposal is useful and
good enough, or if we need something else. I do encourage people to
consider this. However, considering Simon Perrault's comment, I do want
to state that I share Harald's view that this prioritization behavior
needs to be consistent over the implementations.

11. Section 4.2:
   This prioritization is independent of the
   media type, but will lead to packet loss due to full send buffers
   occuring first on the highest volume flows at any given priority
   level.

I think I have two questions here. First, I appears that you assume that
you have an API model where the framework will try to send and fail
rather than creating the data based on allowance or with the knowledge
that you can send a particular data amount. I think creating sender side
buffer overflow is a poor regulation model.

Secondly, I would not that this issue has a higher probability of
effecting the flow with most data first.

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: [email-masked]
----------------------------------------------------------------------

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 25 Apr 2014 17:02:23 +0200

> can't imagine a situation where that would happen if we leave it open.

I can imagine that happening. Consider a scenario where complete 
starvation is considered a Really Bad Thing.

if (firefox) {
    // higher priority channels will completely starve out lower 
priority ones. Don't.
   priority = normal
} else if (chrome) {
    // lower priority channels will get some packets through. That's OK.
    priority = high
} else {
    // I have no idea what will happen, let's play it safe.
    priority = normal
}

---

From: Simon Perreault <[email-masked]>
Date: Fri, 25 Apr 2014 11:17:07 -0400

Le 2014-04-25 11:02, Harald Alvestrand a écrit :
>    // higher priority channels will completely starve out lower priority
> ones. Don't.
>   priority = normal
> } else if (chrome) {

Ok, then how about "MUST NOT do starvation"?

I'll shut up now. I see your point. If nobody else feels this issue is
important, feel free to ignore my comment.

Simon

---

From: Martin Thomson <[email-masked]>
Date: Fri, 25 Apr 2014 10:00:31 -0700

> important, feel free to ignore my comment.

Honestly, I was originally inclined to agree with you, but the SHOULD
leaves plenty of wiggle room for those who think they know better.

I think that providing motivation in the document - something like
"This ensures that lower priority streams receive fewer resources, but
cannot be completely blocked by those at higher priority." - would
help to ensure that people who think they know better - and don't -
can't screw things up too much.

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Fri, 25 Apr 2014 17:03:09 +0000

If a "lower priority" packet is dispatched before a "higher priority" packet in order to "prevent starvation", then what does "higher priority" mean?

Streams that are deliberately set to take resources from other streams should behave that way. Otherwise the knob shouldn't be labeled the way it is.

Matthew Kaufman

> -----Original Message-----
> From: rtcweb [mailto:[email-masked]] On Behalf Of Martin
> Thomson
> Sent: Friday, April 25, 2014 10:01 AM
> To: Simon Perreault
> Cc: [email-masked]
> Subject: Re: [rtcweb] Prioritization
> 
> Honestly, I was originally inclined to agree with you, but the SHOULD leaves
> plenty of wiggle room for those who think they know better.
> 
> I think that providing motivation in the document - something like "This
> ensures that lower priority streams receive fewer resources, but cannot be
> completely blocked by those at higher priority." - would help to ensure that
> people who think they know better - and don't - can't screw things up too
> much.
>

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Fri, 25 Apr 2014 17:06:21 +0000

Harald Alvestrand:
> - "More" has a numeric value, so behaviour is predictable (that's where the
> x2 figure came from)

The above is simply wrong, so the text shouldn't capture it at all.

If I say that audio is more important than video, and I try to send 100kbps of audio and 3 Mbps of video over a 101kbps channel, how much audio should I drop at send time to let video through?

Matthew Kaufman

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 25 Apr 2014 20:30:58 +0200

> If I say that audio is more important than video, and I try to send 100kbps of audio and 3 Mbps of video over a 101kbps channel, how much audio should I drop at send time to let video through?
Is either stream adaptive?

If I send high quality OPUS (100 Kbits/sec) and VP8 in HD (3 Mbits/sec), 
the suggested result would likely be OPUS scaled down to ~60 Kbits/sec 
and VP8 scaled down to ~30 Kbits/sec.

The latter is probably useful for recognizing that there was an 
intention to send a picture.
This MAY be a fine result, depending on the application's requirements.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 30 Apr 2014 21:09:19 +0000

> If a "lower priority" packet is dispatched before a "higher priority" packet in order to "prevent starvation", then what does "higher priority" mean?

I think the labels reflect what "might" happen on average and not for any particular packet. I say "might" because in some deployments it possible the values will have no effect at all and it is possible to construct bizarre environments where you could get the opposite of the desired behavior in some cases. None of that bothers me as the label still seem like the closest to helping developers request the desired treatment. With all things qos like, the best we can for is desired outcome and not what will necessarily happen on internet. 

priority might be better called "desired priority" and the values of "very low, low, med, high" might better be called "broccoli, apple, orange, cherry" - they are really just some labels that describe how the packets *might* be queued by systems they pass through.  I think the fruit labels would be more confusing to web programmers.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 30 Apr 2014 14:23:26 -0700

On 30 April 2014 14:09, Cullen Jennings (fluffy) <[email-masked]> wrote:
> I think the labels reflect what "might" happen on average and not for any particular packet.

I think that Matthew was referring to the part where the browser is
involved.  That is, the bit where, when presented with the option to
send just one packet from buckets A through D, how does it choose from
those buckets.

The implication was that if A is more important than B, then if A
wants to send, it gets to send.  Period.  The "prevents starvation"
view of the world says that work is shared between A-D, with
increasingly large proportions of the available capacity given to
higher priority streams.  The problem with both these models is that
they are crap in various ways.  In one, you get cases where lower
priority stuff never happens, even if that isn't what you wanted; in
another, lower priority stuff can get resources, and that wasn't what
you wanted.

The DSCP markings and how they might interact with this are just an
additional layer of uncertainty, primarily.

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Wed, 30 Apr 2014 21:36:32 +0000

> From: Martin Thomson [mailto:[email-masked]]
> Sent: Wednesday, April 30, 2014 2:23 PM
> To: Cullen Jennings (fluffy)
> Cc: Matthew Kaufman (SKYPE); Simon Perreault; [email-masked]
> >> If a "lower priority" packet is dispatched before a "higher priority" packet
> in order to "prevent starvation", then what does "higher priority" mean?
> >
> I think that Matthew was referring to the part where the browser is involved.
> That is, the bit where, when presented with the option to send just one
> packet from buckets A through D, how does it choose from those buckets.
> 
> The implication was that if A is more important than B, then if A wants to
> send, it gets to send.  Period.  The "prevents starvation"
> view of the world says that work is shared between A-D, with increasingly
> large proportions of the available capacity given to higher priority streams.
> The problem with both these models is that they are crap in various ways.  In
> one, you get cases where lower priority stuff never happens, even if that
> isn't what you wanted; in another, lower priority stuff can get resources, and
> that wasn't what you wanted.
> 

Accurate summary of my position.

Matthew Kaufman

---

From: Dave Taht <[email-masked]>
Date: Wed, 30 Apr 2014 14:46:01 -0700

>> that wasn't what you wanted.

It is extremely rare that you want a starvation queue. Two examples are
holding a port open through a natted device, and your typical keepalives.

If you want to support near-starvation queues, you could specify an outer
bound for the maximum time a lower priority queue can be starved.

otherwise a system of weights seems more appropo.

-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article

---

From: "DRUTA, DAN" <[email-masked]>
Date: Thu, 1 May 2014 04:00:24 +0000

We discussed this a while back and to a certain extent is a split problem between the API and the protocol.

If we look from developer's point of view, they are the ones that know within their app what's more important.
For a game data channel might be more important than video where for a customer service app audio might be more important than video (could be the opposite if it's a furniture store and showing how to assemble a piece of furniture is far more important).
The point is that it starts with the API and hopefully we will get something that will give the browser a hint on the track priority.
This indication should be used for two purposes:
	1. Plug in a common congestion control between media and data within the browser implementation, try to honor this application demand and potentially balance it with other web applications competing for resources and even other applications on the same device.
	2. Allow the browser to mark the traffic accordingly so with additional network support it can be prioritized where possible e2e. It might require an out of band negotiation between the application and the network in order to request and honor the fulfilment of this kind of prioritization where possible.
The relative priority within an app is critical and I'm sure no app developer would mark all of their tracks as high knowing that it would not do any good.
Ideally we would have an algorithm implemented consistently across the board within browsers so developers would know what to expect but the algorithm must take input from the app as a factor into its decision.

Dan