Re: [rtcweb] [tram] Payload Types assignments

["Charles Eckel (eckelcu)" <[e-mail]>]

It may have been mentioned previously, but those interested in this may
well want to have a look at the following drafts being discussed on the
AEON list ([e-mail]):

http://tools.ietf.org/html/draft-eckel-aeon-problem-statement-00
http://tools.ietf.org/html/draft-eckel-aeon-use-cases-00

While QoS is not the sole focus of this work, it is one of the important
work flows prevalent in networks today that is more challenging in the
face of emerging communication applications such as those enabled by
WebRTC. One of the goals of the AEON effort is to provide a framework such
as the one mentioned by Magnus.
Comments on the AEON list are welcome, as is your attendance at the AEON
side meeting at IETF 89:
http://www.ietf.org/mail-archive/web/aeon/current/msg00018.html

Cheers,
Charles


On 2/25/14, 12:39 AM, "Magnus Westerlund" <[e-mail]>
wrote:

>Karl,
>(As individual)
>
>I also wish for more usable QoS mechanisms. However, I don't see that
>being achieved by your proposal. In addition I agree with Colin about
>the issues with putting the information in the RTP header extension. I
>would also note that this would be very RTP specific, and not at all
>help with the data channels multiple streams and their priorities. There
>might be data channel information that is more crucial than any of the
>RTP media stream packets.
>
>You are pushing for a small piece in the middle. A piece that will not
>help with the more general issue of QoS. How does the application and
>the multiple ISPs that carries the traffic reach an agreement on what
>properties that can be provided, that the application in this instance
>have the right to request those properties and that any cost is
>correctly associated with the user or the user's agent in regards to
>carrying the associated cost.
>
>When it comes to setting DSCP from user land in the OS, that is
>restricted due to the security implications. If those implications where
>resolved, then OS could open up those interfaces.  There are many
>interlinked reasons why things look like they do today. I don't believe
>in tugging on a single random thread in ball of yarn and hope that it
>comes out without any knots and ties on it.
>
>Show me the framework for the QoS functions you have in mind that at
>least has less issues than the currently deployed and take care of at
>least some of the bigger issues. If that requires information in the RTP
>streams for some reasons, then let us talk about how to best encoded it.
>But, we need that framework first, the architecture that makes this a
>better solution than the current Diffserv architecture or any other QoS
>architecture.
>
>Cheers
>
>Magnus Westerlund
>
>----------------------------------------------------------------------
>Services, Media and Network features, Ericsson Research EAB/TXM
>----------------------------------------------------------------------
>Ericsson AB                 | Phone  [phone]
>Färögatan 6                 | Mobile [phone]
>SE-164 80 Stockholm, Sweden | mailto: [e-mail]
>----------------------------------------------------------------------
>
>_______________________________________________
>tram mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/tram