Re: [rtcweb] Some language on "prioritization"

["Karl Stahl" <[e-mail]>]

-----Ursprungligt meddelande-----
Från: Simon Perreault [mailto:[e-mail]] 
Skickat: den 22 april 2014 15:46
Till: Karl Stahl; 'Pal Martinsen (palmarti)'; 'Harald Alvestrand'; 'Magnus
Westerlund'
Kopia: [e-mail]
Ämne: Re: SV: [rtcweb] Some language on "prioritization"

Le 2014-04-21 08:13, Karl Stahl a écrit :
> 1) AVOIDING SELF DESTRUCTING PRIORITAZATION FROM FILE TRANSFER IN DATA 
> CHANNEL
> 
> Simon,
> 
> I saw you are an author of TURN-TCP RFC6062. Doesn't that RFC allow a 
> webrtc file transfer channel (separate from the rtcweb data channel) 
> to be created, using TLS file transfer P2P? ICE/STUN/TURN would set it 
> up, NOT BUNDLED with chunk data and RTP media.

RFC6062 knows nothing about WebRTC or TLS inside the peer connection
payload. So it doesn't explicitly "allow" what you suggest. But I guess it
doesn't prevent it either. It doesn't care.

[Karl] OK (just realized TURN was not limited to setting up UDP with
TURN-TCP RFC6062 now available), so meant "allow" in the sense: Fine, we can
use TLS for file-transfer, rather than new/complex UDP with DTLS with SCTP. 

> Freeing the current rtcweb data channel from file transfer would 
> remedy the self destruction of prioritization/QoS for data chunks and 
> RTP media as explained in (A), (B) and (C) below.
> 
> I also think it would be much better for a web programmer to have a 
> separate p2p file transfer channel (that is not and cannot be 
> prioritized) than pouring files into the data channel.

Why do you think using a separate channel would eliminate the issue of
prioritization? We would end up with multiple channels contending for the
same bandwidth. You have just moved the problem one level up. And made
things needlessly more complex, IMHO.

[Karl] The (A) and (B) and (C) at the bottom in the email you answered
DESTROYS the QoS/Prioritization we are used over the Internet (By SCTP data
channel mixing real-time stream data with filling the pipe (congesting
creating) file transfer data in the same bundle/flow/5-tuple).

SCTP's own prioritization mechanism can only act on what is in the
endpoint's buffers - SCTP cannot help/remedy congestion happening IN THE
NETWORK where its data transfer has caused congestion when competing with
other parties file transfer TCP flows, and there filled a network buffer
with the mixture of our own file transfer AND REAL-TIME data. 

Yes, pouring a file into current data channel will even cause QoS damage to
our own bundled Video/Voice that SCTP's prio-mechanism cannot fix, because
it cannot rearrange what is queued up in a Network buffer.

First after getting back to having file transfer separated out of the bundle
in another flow/5-tuple can we start thinking about improving
prioritization/QoS for real-time data.


[Karl] I wrote this sometime before, regarding how QoS over the internet
works in general - may be useful for understanding

For better understanding of these QoS/QoE problems, and methods for
improving (not specifically discussing the policies of sharing real-time
traffic space), I would like to explain:

Over an IP pipe only used for real-traffic (no TCP data traffic), it is
sufficient that the pipe is wide enough for good QoS. That is often used and
implemented by separating IP pipes at a lower level using e.g. Ethernet
VLAN, MPLS, Ethernet over ATM (std for ADSL modems). TURN servers can
enforce real-traffic into such pipes and QoS is achieved. Let’s call this
Level 2 QoS (Network level)

Over an IP pipe shared between quality requiring real-time traffic and less
demanding data or streaming (usually TCP) traffic, we have the sharing
between these two traffic classes to consider. The main method (and the
mechanism making today’s real-time QoE as good as it often is) is that TCP
endpoints back-off and share their bandwidth usage. Real-time traffic using
UDP transport do not back-off, the endpoints using UDP occupy the bandwidth
needed. When an IP pipe gets filled, it is all endpoint’s TCP bandwidth
usage that is back-off and shared between them, leaving room for the UDP
traffic. This is mechanism we experience everyday over the Internet, using
our “Surf IP pipes”. Let’s call this Level 4 QoS (Transport level)

However, this Level 4 QoS is based on that at congestion times (which happen
every time we click – setting up a TCP flow and transferring some amount of
data as quick as possible) the router handling the most narrow part of the
pipe (the congestion point) drop packets. It is this packet dropping that
(i) signals to TCP endpoints to reduce their bandwidth (via TCP’s error
correction/retransmission mechanism) and (ii) destroys the QoE of real-time
traffic. (Both TCP and UDP packets are dropped in this process that is
triggered by flow intensive TCP traffic.)

We need (i) but don’t want (ii) and to improve on this we can e.g. use
diffserve, DSCP bits in IP packets to instruct routers to always forward the
real-time traffic before any unmarked TCP traffic (which usually fills most
of the pipe). Then QoS is then achieved for real-time traffic. This is Level
3 QoS (IP level). The method used is “traffic shaping”: backing off data
traffic, leaving real-time traffic free passage without packet loss.

Here, in TRAM we want to go beyond Level 4 QoS (already available and
working as good as it can on the Internet), to give quality demanding WebRTC
real-time traffic better QoE by:
a. Forcing real-time traffic into IP-pipes having Level 2 QoS (using
auto-discovered TURN servers) 
or
b. Forcing real-time traffic into IP-pipes having Level 3 QoS (using
auto-discovered TURN servers). Here we must have traffic shaping mechanisms
working, and with correct and sufficient information to do the job. This is
why we in TRAM discuss DISCUSS/MALICE,
draft-thomson-tram-turn-bandwidth-00.txt attributes and recreating the
payload type (PT) idea/intent in RTP packets (by now conveying bandwidth and
traffic type in the RTP extension header
http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html.

How these QoS/QoE things are done and used in practice is also
illustrated/exemplified in this email discussion:
http://www.ietf.org/mail-archive/web/rtcweb/current/msg09031.html 

Prioritization of individual real-time packets (e.g. using diffserve DSCP
bits) have today little impact on the QoE, UNLESS a pipe full with only
real-time traffic (which is unusual), because in today’s IP pipes with high
bandwidth, packets are not stored for later delivery, but rather dropped by
routers implementing diffserve (after only a short time period = small
buffer size). The only good remedy is higher bandwidth, that can handle ALL
real-time traffic. 

Prioritization of real-time packets (any diffserve DSCP bits marking) “makes
QoS perfect”, when there are best effort (=no DSCP bits set) TCP (=non
real-time) traffic going over the IP pipe that can be pushed off. Routers
implementing diffserve do that.



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