Re: [rtcweb] Protesting the QoS document decision

[Gonzalo Camarillo <[e-mail]>]

Hi,

[adding Subha, the main author of the draft, to the cc:]

Subha intends to revise the draft before the end of this month. She will
try and address the comments below from Wes.

Cheers,

Gonzalo

On 14/11/2013 8:38 PM, Ted Hardie wrote:
> On Thu, Nov 14, 2013 at 9:19 AM, Wesley Eddy <[e-mail]
> <mailto:[e-mail]>> wrote:
> 
>     On 11/14/2013 3:10 AM, Gonzalo Camarillo wrote:
>     As for the current status, the document does not yet address
>     core issues that have been pointed out.  See, for instance:
>     http://www.ietf.org/mail-archive/web/tsvwg/current/msg12042.html
> 
>     People interested should work on this in TSVWG.  There does not
>     seem to be any reason for RTCWEB to be gated on it, as it has zero
>     impact on interoperability or the protocol.  Having a normative
>     reference to it is not correct and is easy to fix.
> 
>     --
>     Wes Eddy
>     MTI Systems
> 
> 
> 
> Hi Wes,
> 
> The issue raised isn't that there is an RTCWEB document gated on it, but
> that shipping code does require this to be resolved.  The message you
> point to above notes a core issue, which I assume is this:
> 
> That said, I think the interesting facet of this document is that
> packets within the same flow (defined by 5-tuple of address-port
> pairs and protocol number) are receiving different codepoints, and
> the implications of that for a CC that may be on top of them need
> to be delved into. 
> 
> 
> I think the authors may not have seen "interesting facet" 
> as a clear enough signal that they were blocked on this.  
> Can you restate this problem to them, so that they understand either
> where in the document they should raise the issue or where there is work they can reference
> for incorporation?
> 
> You may want to include pointers on why having this situation,
> 
> versus multiple flows going between the same end points in
> 
> other contexts, is a problem.  I'm kind of concerned as well
> that they will take the simple solution (use the most stringent
> 
> QoS), which is clear enough from a congestion control perspective
> 
> but bad from other perspectives.
> 
> regards,
> 
> 
> Ted
>