Re: [rmcat] Shared Congestion state & draft-dhesikan-tsvwg-rtcweb-qos

["Mo Zanaty (mzanaty)" <[e-mail]>]

Folks should also be aware that RFC 4594 is being updated, and that is the best place to propose a separate DSCP for RMCAT traffic (or delay-adaptive traffic in general, although you could argue RMCAT and LEDBAT should also be kept separate).

http://tools.ietf.org/html/draft-polk-tsvwg-rfc4594-update-03

Mo

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Michael Ramalho (mramalho)
Sent: Friday, July 12, 2013 9:47 AM
To: [e-mail]; [e-mail]
Cc: [e-mail]
Subject: Re: [rmcat] Shared Congestion state & draft-dhesikan-tsvwg-rtcweb-qos

Gorry,

Your recollection regarding the desire for a separate DSCP code point for "RMCAT flows" is correct.

To review for everyone else here, when a RMCAT flow competes in a bottleneck queue where the dominant traffic flows into that queue possess congestion control that adapts based on loss (e.g., long-lived TCP flows), the RMCAT flow is stuck with a delay of whatever the maximum queuing delay through the queue is. This situation is not desirable because the interactive applications that desire RMCAT transport desire low delay (i.e., to minimize any potential bufferbloat).

So, while it is a given that a RMCAT flow must live (survive) when it finds itself in such a traffic aggregate, the RMCAT flow would "prefer" to exist in a traffic aggregate that does not require queue overflow when the other flows adapt. This is desirable because a lower delay is possible relative to the former.

It is for this reason that RMCAT desires a separate DSCP code point. And some RMCAT participants voiced that desire at the Orlando IETF transport working group meeting.

Draft draft-dhesikan-tsvwg-rtcweb-qos is a draft whose intension was to map the EXISTING DSCPs into something RTCWeb could use today (draft authors may correct me if I am wrong). Given the recent nature of the RMCAT request (for a separate DSCP codepoint) to the transport WG - that request has not been incorporated into the Dhesikan draft yet.

I have offered to craft a few sentences for inclusion into the Dhesikan draft explicitly stating the desire for a new codepoint is recognized, but that the draft only deals with the EXISTING codepoints (i.e., those defined by RFC 4594).

I think this is the correct approach, as I think it is wise to provide RTCWeb applications designers with some guidance prior to the completion of RMCAT work. Comments are welcome.

My $0.02,

Michael Ramalho

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Tuesday, July 09, 2013 4:18 AM
To: [e-mail]
Cc: [e-mail]
Subject: [rmcat] Shared Congestion state & draft-dhesikan-tsvwg-rtcweb-qos

I's like to solicit feedback on draft-dhesikan-tsvwg-rtcweb-qos, proposed as a work item in tsvwg.
This was brought to TSVWG for consideration because it discusses transport mappings to QoS intended for RTCweb.

At a previous RMCAT WG meeting it was mentioned that this advocates use of separate QoS code points for different streaming components.  At that time it was suggested that use of several QoS code points for different streaming components would result in flow-isolation between the different RTCWeb subflows and that this could potentially conflict with design goals in RMCAT that seek to use coupled congestion state between subflows. It would be helpful to know if this draft does impact this and what issues need to be considered.

Please *do* provide feedback to tsvwg on this topic. We plan to discuss this in Berlin.

Gorry
(TSVWG Co-Chair)