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

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

Hi Alan,

 

I have in previous email
http://www.ietf.org/mail-archive/web/tram/current/msg00304.html suggested
that both DISCUSS and draft-thomson-tram-turn-bandwidth-00.txt is taken off
the TRAM WG, but I think is shall be reintroduced after you clarify as you
do in 

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

Hi Karl, Thanks for your comments and feedback on the draft.

You are correct in saying that the BANDWIDTH extension is not about QoS.  It
is about fairness between users of a TURN server, and a TURN server being
able to indicate rate limiting policy to users. in the draft.

 

The “confusion” (to say least, see below) surrounding QoS within IETF has
lead me to protest and address the TRAM WG and RTCWEB WG and ADs with the
advise in http://www.ietf.org/mail-archive/web/tram/current/msg00304.html :

“The TRAM WG and RTCWEB WG chairs and ADs are advised to review whether IETF
standard work in these WGs by contributors having an interest in more than
one of current or emerging: ISPs, carrier equipment vendors or web browser
makers, may discriminate any with an interest only in one of these. The same
should apply to non-activity by WG contributors to remedy such
discrimination opened by allowed proprietary usage of RFCs such as RFC
5285.” 

 

This is because the introduction of the QoS related usage of RFC 5285 into
draft-ietf-rtcweb-rtp-usage in combinations with the Milestone 3 objectives
of TRAM, immediately would allow for:

(1) *all* protocols using IETF RTP/SRTP and/or IETF TURN/STU/ICE (in
addition to WebRTC: e.g. SIP, Skype and Facetime, and most VoIP variants) to
quickly allow us to finally enjoy the high quality and connectivity
(NAT/firewall traversal) of real-time communication services now possible,
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 the Internet (including OTT).

 

While the “confusion” surrounding the QoS discussion in TRAM and RTCWEB
combined with the general QoS attitude within IETF “it is all about
bandwidth” and “it will go away with time” otherwise:

(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. That all networks *will 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*)

*while* newer, fiber only type of networks, still can 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 have 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).

 

As Good doers, we should not allow this to happen.

 

/Karl

 

 

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

 

I guess the way I would expect this to progress is for QoS discussions to
happen in another working group.  Once that other working group came to
consensus on an approach, and if that approach required STUN or TURN
extensions, then we would discuss mechanisms and possible milestones in
TRAM.

 

- Alan -

 

On Fri, Feb 21, 2014 at 3:37 AM, Pal Martinsen (palmarti)
<[e-mail]> wrote:

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) <
<mailto:[e-mail]> [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