[rtcweb] Last note about QoS from the responsible AD before the rant ...

[Spencer Dawkins at IETF <[e-mail]>]

Using smaller words (since we're all very busy):

QoS is out of scope for TRAM.

It is in scope for TSVWG.

It will not be necessary helpful to continue to talk about QoS in TRAM.

Thanks for taking the conversation to a mailing list where it's in scope.

Spencer, as responsible AD

On Tuesday, February 25, 2014, Cullen Jennings (fluffy) <[e-mail]>
wrote:

>
> Karl,
>
> I am totally lost on this thread. Could you start a new tmead that
> summarize what the issues is, what seems to be the point of debate, and
> what your view is on what we should do. I think that would help make
> progress.
>
> Thank you,
>
> Cullen
>
>
> On Feb 25, 2014, at 8:20 AM, Karl Stahl <[e-mail]<javascript:;>>
> wrote:
>
> > 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 thegeneral 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] <javascript:;>]
> > Skickat: den 21 februari 2014 18:59
> > Till: Pal Martinsen (palmarti)
> > Kopia: [e-mail] <javascript:;>; 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] <javascript:;>> 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) <[e-mail]<javascript:;>>
> 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] <javascript:;>] On Behalf Of
> Oleg Moskalenko
> > Sent: Thursday, February 20, 2014 12:43 PM
> > To: Alan Johnston
> > Cc: Karl Stahl; [e-mail] <javascript:;>
> > 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 <
> [e-mail] <javascript:;>> 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] <javascript:;>
> > https://www.ietf.org/mailman/listinfo/tram
> >
> >
> > _______________________________________________
> > rtcweb mailing list
> > [e-mail] <javascript:;>
> > https://www.ietf.org/mailman/listinfo/rtcweb
>
> _______________________________________________
> rtcweb mailing list
> [e-mail] <javascript:;>
> https://www.ietf.org/mailman/listinfo/rtcweb
>