Re: [tsvwg] FW: New Version Notification for draft-dhesikan-tsvwg-rtcweb-qos-00.txt

[<[e-mail]>]

Wes,

thanks. (2) may advocate starting with a problem statement and a framework on QoS
for RTCWeb. I'd support that.

Regards,

Rüdiger


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Wesley Eddy
Sent: Thursday, December 20, 2012 10:45 PM
To: [e-mail]
Subject: Re: [tsvwg] FW: New Version Notification for draft-dhesikan-tsvwg-rtcweb-qos-00.txt

On 11/27/2012 7:27 PM, Subha Dhesikan (sdhesika) wrote:
> This document was originally submitted in RTCWeb WG and was adopted as a WG document.  The transport AD requested that this be moved to TSVWG. Therefore, this document is now submitted as an individual submission to TSVWG.


To provide some context ... during the Atlanta IETF, it
became clear that having this document in RTCWEB (where
it was a WG draft) was confusing on at least 2 counts:

(1) TSVWG is the place in the IETF where we should be
    making any recommendations about use of DiffServ;
    it would get crazy if every WG had its own set of
    guidance about this.

(2) It seemed to be advocating using multiple 6-tuples
    (address pairs, port pairs, protocol, and DSCP) that
    differ only in their DSCP, for distinguishing the
    QoS desires of individual packets within an RTCWEB
    flow that's muxing potentially lots of different
    things (voice, video, bulk, and interactive data)
    with different QoS desires.

    This was potentially not going to interact well
    with things we have been talking about in RMCAT,
    like allocating congestion responses between
    elastic and inelastic sub-flows.  If those sub-
    flows are on separate 6-tuples, this may not
    make any sense, as they'd be seeing different
    queues within the network.

So, in summary, TSVWG is the right place to talk about
this draft, though I'm not sure it's technically a very
good idea, myself, given other work being done in the
IETF currently.

--
Wes Eddy
MTI Systems