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

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 19 Feb 2014 15:45:04 +0000

> -----Original Message-----
> From: tram [mailto:[email-masked]] On Behalf Of Simon Perreault
> Sent: Wednesday, February 19, 2014 3:03 AM
> To: [email-masked]
> Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt
> 
> Le 2014-02-18 16:12, Oleg Moskalenko a écrit :
> > How to handle the DS and ECN fields is a part of TURN server RFC (see
> > the section 12):
> >
> > http://tools.ietf.org/search/rfc5766#section-12
> >
> > And a good TURN server is supposed to implement that.
> 
> Well, the RFC just says that the TURN server should copy the DSCP from one side
> to the other when doing en/de-capsulation. It doesn't say that the server should
> actually do QoS based on the DSCP. My point is that there's nothing preventing
> the server from actually doing it.
> 
> Anyway, I was expecting responses along the lines of "DiffServ doesn't work on
> the Internet in general." 

Yes, the other problem is some OS like Windows (http://support.microsoft.com/kb/248611) do not support setting DSCP.

-Tiru

> To which I would have replied: "then couldn't we define
> a STUN attribute for transporting the DSCP in the payload?" Instead of inventing
> a new taxonomy (audio, video, slides, etc.), why not reuse DSCP?
> 
> Simon
> --
> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
> NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
> STUN/TURN server               --> http://numb.viagenie.ca
> 
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 19 Feb 2014 15:48:02 +0000

> Sent: Wednesday, February 19, 2014 7:04 PM
> To: [email-masked]
> Le 2014-02-18 17:35, Paul Kyzivat a écrit :
> > On 2/18/14 5:08 PM, Oleg Moskalenko wrote:
> >> TURN/STUN has been a binary protocol, so far... bringing SDP into the
> >> picture would make it too complicated.
> >
> > I didn't mean that. I just meant that the taxonomy could potentially
> > be adopted in some way.
> >
> > (Whether that is a good idea is another story. I haven't followed the
> > work closely. It isn't obvious to me that the particular taxonomy is
> > well justified.)
> 
> And we need to keep in mind that TURN is a generic traversal mechanism usable
> by more than just real-time media...

Good point and explicitly signaling Audio, Video, Data channels,  file transfer etc. could cause to keep enhancing the list in future with avatar,  smellovision etc.

http://tools.ietf.org/search/rfc5897#section-6.3

<snip from section 6.3>

   Consider the following example.  Several providers get together and
   standardize on a bunch of service identifiers.  One of these uses
   audio and video (say, "multimedia conversation").  This service is
   successful and is widely utilized.  Endpoints look for this
   identifier to dispatch calls to the right software applications, and
   the network looks for it to invoke features, perform accounting, and
   provide QoS.  A new provider gets the idea for a new service (say,
   "avatar-enhanced multimedia conversation").  In this service, there
   is audio and video, but there is a third stream, which renders an
   avatar.

</snip>

-Tiru