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) <
palmarti@cisco.com> 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) <yoakum@avaya.com>
> 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:tram-bounces@ietf.org <tram-bounces@ietf.org>] *On
> Behalf Of *Oleg Moskalenko
> *Sent:* Thursday, February 20, 2014 12:43 PM
> *To:* Alan Johnston
> *Cc:* Karl Stahl; tram@ietf.org
> *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 <alan.b.johnston@gmail.com>
> 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
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram
>
>
>