Re: [rtcweb] [tram] I-D Action: draft-thomson-tram-turn-bandwidth-00.txt

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

Hi Pål,

 

You did not comment nor answer, in response to any of:

http://www.ietf.org/mail-archive/web/tram/current/msg00275.html 

http://www.ietf.org/mail-archive/web/tram/current/msg00273.html 

whether step D) can obsolete step C) (DISCUSS/MALICE) by allowing the
application/browser to transfer relevant real-time traffic information
(types and bandwidth) into every RTP package by using the already IETF
standardized RTP extension header RCF 5285, which could be used by any
current or future Internet (including OTT) network where WebRTC real-time
traffic may flow. It seems to have been standardized already 2008 to allow
such usage.

 

QoS related step C) draft-martinsen-tram-discuss can then be taken out of
TRAM, and step D) (that was never intended to be handled by TRAM anyway)
will be handled elsewhere.

 

I have repeated my suggestion to RTCWEB WG from the October discussions on
the relevant [rtcweb] [avtext] [mmusic] lists
http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html to
introduce the QoS related step D) into draft-ietf-rtcweb-rtp-usage
suggesting usage of RFC 5285, where traffic information in RTP packets
simply would be filled by any browser under any OS.

 

Without step B), TRAM “Enforcing the real-time traffic through the
offered/discovered TURN servers”, the real-time traffic may happen through
the IP default gateways often congested by data traffic and QoS insensitive
streaming video and file sharing. Without specific QoS methods at those
points, the network raw bandwidth capacity may have to be 10-folded to
achieve sufficient QoE when WebRTC usage becomes popular. Methods like
DISCUSS addresses such things occurring when STUN instead TURN is used (by
allowing flows into such congestion points), but only provides direct
traffic info for outgoing (not incoming) real-time traffic and locally,
therefore are not even applicable to reservation type of networks like Cable
Networks and Mobile OTT. 

 

That would leave certain network types to investing in raw bandwidth
increase, instead of simply borrowing the bandwidth (from much larger data
traffic and QoS insensitive streaming video and file sharing at no adverse
effect) and making that borrowed no-cost bandwidth very valuable for the
carriers when delivering to their customers.

I know a few of you Cisco guys are among the ones that have been fighting
against the general “it is all about bandwidth” and “it will go away with
time”-attitude within IETF work, e.g. see
http://www.ietf.org/mail-archive/web/rtcweb/current/msg09031.html, but the
pointers given in the current QoS discussion within TRAM: 

 

(i) will *not allow* ISP’s to use already available and currently deployable
quality IP pipes for real-time traffic to also be used for WebRTC generated
real-time traffic.

 

(ii) will *not allow* some network types (e.g. Cable Networks and Mobile
OTT) to borrow bandwidth from data traffic and QoS insensitive streaming
video and file sharing. All networks will *also be inhibited* from the very
common and used method of simply providing an extra IP pipe (often provided
over the same wire but level-2 separated) dedicated for real-time usage

(*by resisting TRAM implementation of step B*)

Newer, fiber only type of networks, can still borrow bandwidth at no extra
cost, *by proprietary usage* of RFC 5285 by browsers. 

 

(iii) will leave most ISPs to *only use* raw bandwidth capacity increase
that may has to be 10-folded to reach sufficient QoE when WebRTC usage
becomes popular (if at all possible, since unmanaged IP pipes intermittently
are filled, whatever bandwidth is available).

 

Further explainations about QoS methods and their implementation were given
a few days ago in: 

http://www.ietf.org/mail-archive/web/tram/current/msg00274.html 

 

(i), (ii) and (iii) will *seriously delay* usage of telepresence capable and
quality demanding WebRTC (bandwidth being around 30 times higher over best
effort Internet, than telephony over quality managed networks) and will
*vastly increase cost* for ISPs to offer WebRTC with good QoE.

 

Below you are giving pointers saying “They are currently working on a
problem-statement draft and a use-case draft, any input to those would be
very helpful.” Those are unnecessary, risking leading to (i), (ii) and (iii)
above.

 

So are pointers such as: “RMCAT where congestion avoidance for RTP is being
developed”. TRAMs Milestone 3 is for the purpose of directing real-time
traffic where congestion control isn’t already in place. Using RFC 5285
available since 2008, to fill traffic information in RTP packets (step D))
is probably a necessity for most future “congestion control” discussed.

 

This chicken-and-egg circular also applies to RTCWEB direction of QoS issues
to: 

http://datatracker.ietf.org/doc/draft-dhesikan-tsvwg-rtcweb-qos 

focusing on DSCP-mapping without even mentioning RFC 5285 available since
2008, to fill traffic information in RTP packets where it  is a necessity
and will allow: 

(1) applications to directly convey QoS related real-time traffic info to
the network at points where RTP flow is directed to by TRAM Milstone 3, to
be used by *any network element implementing any suitable QoS methods for
the particular network* for 

(2) *all* WebRTC browsers *and* dedicated clients (not using WebRTC), under
*all* OSs, and *all* current and future IP networks 

(3) *without* having to be forced into application specific networks (PSTN,
IMS) instead of using the Internet (including OTT).

 

The only activity required, is to call for ISPs’ review whether the traffic
information transferred by RFC 5285 is sufficient for current and future
needs in their network as suggested in
http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html

<snip>

…two parameters (e.g. two bytes each) are encoded into the RTP header
extension:

 

A) The maximum bandwidth requirement: Two bytes could contain everything
from some bps for real-time text to Gbps for future 3D supersize
telepresence… on a logarithmic scale.

 

B) The quality characteristics for the stream, with the highest bit set to
1, we could allocate a bit each for quality type e.g:

Best Effort, Audio, Video, Supplemental Video, Gaming, Data, Delay
Insensitive (e.g. video streaming), Minimum Delay, Reliable Delivery,
Prioritize X, Variation Y, that could be combined as required to describe
the stream.

 

And with highest bit set to 0, there could instead be a number for special
usage that does not fit the general description of the individual bits.

</snip>

 

Then this could be assigned numbers to have the RFC in place.

With TRAM milestone 3 also place, 

market forces will drive ISPs and browser makers to implement just that,
without even having it MUST-established.

“Who does not want a “WebRTC-Ready” Internet access?” and

“Who wants to use Chrome, if Firefox, Internet Explorer or Safari comes with
much better QoE?” and vice versa.

 

Please see further emails soon following this one, for details and history.

 

/Karl

 

Från: tram [mailto:[e-mail]] För Pal Martinsen (palmarti)
Skickat: den 21 februari 2014 10:37
Till: [e-mail]
Kopia: Karl Stahl; Oleg Moskalenko; Alan Johnston; Yoakum, John H (John)
Ämne: Re: [tram] I-D Action: draft-thomson-tram-turn-bandwidth-00.txt

 

Hi,

 

I agree the full QoS discussion should _not_ happen in TRAM. If you are
interested in helping out in that area I suggest you looking into the AEON
mailing list at: https://www.ietf.org/mailman/listinfo/aeon . They are
currently working on a problem-statement draft and a use-case draft, any
input to those would be very helpful.
(http://tools.ietf.org/html/draft-eckel-aeon-use-cases-01,
http://tools.ietf.org/html/draft-eckel-aeon-problem-statement-00).

 

That said, STUN have a few nice characteristics that makes it a perfect
candidate for transporting some of the QoS information.  IMHO that would be
extending the STUN spec and should be within the TRAM charter.  The main
goal of draft-martinsen-tram-discuss was to show how already existing QoS
mechanisms could be transported with STUN to provide more value, and to
start the discussion if TRAM is the appropriate place to have those on the
wire format discussions.

 

.-.

Pål-Erik

 

 

 

 

 

 

On 20 Feb 2014, at 19:55 pm, Yoakum, John H (John) <[e-mail]> wrote:





+1

I fully agree with the comments that QOS should be a low priority for the
initial focus of the TRAM efforts.  There are other groups doing QOS work
and frankly I engage in WebRTC multimedia interactions daily over the
Internet, enterprise VPNs, and various combinations and seldom suffer
egregious quality issues.  I am more concerned about carriers doing things
to regulate or degrade WebRTC flows than a failure of existing Internet
mechanisms to enable them.

 

Significant focus on QOS before we better enable TURN to be easily used in a
browser environment taking advantage or normal web characteristics (as
opposed to historic telephony constructs) would seem to be highly
distracting at this point.

 

 

Cheers,

John

 

AVAYA
1.919.425.8446

 

From: tram [mailto:[e-mail]] On Behalf Of Oleg Moskalenko
Sent: Thursday, February 20, 2014 12:43 PM
To: Alan Johnston
Cc: Karl Stahl; [e-mail]
Subject: Re: [tram] Fwd: I-D Action:
draft-thomson-tram-turn-bandwidth-00.txt

 

 

 

On Thu, Feb 20, 2014 at 6:26 AM, Alan Johnston <
<mailto:[e-mail]> [e-mail]> wrote:

 

 

 

Personally, I am not sure how much QoS is actually in scope for TRAM. Have
you been following RMCAT where congestion avoidance for RTP is being
developed?  I see some overlap in your goals and the goals of that work.

-

 

 

I'd concentrate on the TURN application-level functionality, for now, and
I'd leave QoS for the future discussions.




_______________________________________________
tram mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tram