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

Muthu,

Thanks for the feedback on the draft.

I agree that some kind of traffic type indication could also be useful for
the TURN client to indicate to the TURN server the nature of the relayed
traffic.  The TURN server could do this implicitly based on the bandwidth,
although it might have difficulty distinguishing a high quality voice
session from a low quality video session.

Using this indication for QoS could be problematic as you point out, if
TURN clients lie about the nature of the traffic to get a higher priority
than they would otherwise.

- Alan -

On Tue, Feb 18, 2014 at 10:38 AM, Muthu Arul Mozhi Perumal (mperumal) <
mperumal@cisco.com> wrote:

 I think a Traffic Type attribute (audio, video, data) in addition to
> Bandwidth would help the TURN server make better decisions about the
> policies described in the draft, and in particular to the following one:
>
>
>
>     A TURN server might also wish to limit the use of service
>
>     to audio-only sessions, or low bandwidth video and audio
>
>     sessions.
>
>
>
> It might also help SPs who would like to host TURN servers to provide
> differentiated treatment for WebRTC media traffic.
>
>
>
> Of course, there would have to a discussion on what if the application is
> lying about these..
>
>
>
> Muthu
>
>
>
> *From:* tram [mailto:tram-bounces@ietf.org] *On Behalf Of *Alan Johnston
> *Sent:* Tuesday, February 18, 2014 1:44 AM
> *To:* tram@ietf.org
> *Subject:* [tram] Fwd: I-D Action:
> draft-thomson-tram-turn-bandwidth-00.txt
>
>
>
> All,
>
>
>
> We have written a new I-D on a bandwidth attribute for TURN.  The use case
> is to allow a TURN client to indicate to the server the bandwidth it
> expects to use for the relayed candidate, or for a TURN server to indicate
> to the client the maximum bandwidth before the TURN server might apply rate
> limiting.
>
>
>
> Note some of the text is from draft-thomson-mmusic-rtcweb-bw-consent which
> was discussed in the past, but this draft does not propose an ICE use case
> for consent.
>
>
>
> Comments most welcome!
>
>
>
> - Alan -
>
> ---------- Forwarded message ----------
> From: <internet-drafts@ietf.org>
> Date: Thu, Feb 13, 2014 at 9:07 PM
> Subject: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt
> To: i-d-announce@ietf.org
>
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
>         Title           : A Bandwidth Attribute for TURN
>         Authors         : Martin Thomson
>                           Bernard Aboba
>                           Alan Johnston
>                           Oleg Moskalenko
>         Filename        : draft-thomson-tram-turn-bandwidth-00.txt
>         Pages           : 8
>         Date            : 2014-02-13
>
> Abstract:
>    An attribute is defined for Session Traversal Utilities for NAT
>    (STUN) that allows for declarations of bandwidth limits on the
>    negotiated flow.  The application of this attribute is the
>    negotiation of bandwidth between a Traversal Using Relays around NAT
>    (TURN) client and a TURN server.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-thomson-tram-turn-bandwidth/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-thomson-tram-turn-bandwidth-00
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft<https://www.ietf.org/mailman/listinfo/i-d-announceInternet-Draft>directories:
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>