Subject: [rtcweb] Protesting the QoS document decision

From: Harald Alvestrand <[email-masked]>
Date: Wed, 13 Nov 2013 21:21:53 +0100

This mail concerns both administrative and technical issues, which is
why it is explicitly copied to the ADs of RAI and TSV. I hope I have
managed to keep them separate in the message.

Magnus said in an email yesterday, concerning draft-ietf-rtcweb-qos:

> Okay, we might not have been public enough on this. It was requested by
> the Transport ADs quite some time ago that doing the QoS document in our
> WG was not appropriate and requested us to direct the document to TSVWG.
> Which was done, and where it hasn't made progress.
>
> You might have noted that James Polk did comment in the milestone part
> in the monday session of IETF88 about our QoS milestone should be killed.
I want to protest this - both practically and formally.

To get the formal stuff out of the way first:

Changing the deliverables of the working group *without telling the
working group* is totally inappropriate in an open, consensus-driven
process.
Changing the deliverables of the working group *without telling the
working group why* and *without allowing those reasons to be debated* is
totally inappropriate in an open, consensus-driven process.

I protest against this action.

ACTION REQUEST 1: I request that this decision be declared null and
void, and that the relevant ADs send out a message to RTCWEB (and TSVWG
if appropriate) *PROPOSING* such an action, and giving a reasonable
timeline for when they will make a decision based on mailing list feedback.

In practice:

The draft as it existed before its untimely demise consisted of two things:

- A description of how QoS mechanisms could be useful in the RTCWEB use case
- A description of existing mechanisms that could be appropriate for the
RTCWEB use case

The first one is clearly something that needs RTCWEB consensus. It seems
to have no need for, nor likelyhood of gathering interest enough for, a
TSVWG consensus.

There could be some argument that the second part needs TSVWG consensus,
especially if it was redefining any mechanisms, or it was making choices
between mechanisms where TSVWG had strong opinions about which
mechanisms should be chosen, but had not chosen to document that in any
document on which IETF consensus had been declared (that is to say,
existing RFCs).

My archive shows 36 messages where the title refers to this draft. It
shows no messages declaring that feedback has been incorporated and
calling for new review - something that is usually necessary to get a WG
consensus on any document. The debate hasn't been conclusive, but then,
it hasn't been pushed hard either.

The people who know how RTCWEB works are in this working group. Some of
them may be in TSV, but I think the locus of knowledge for saying what
QoS mechanisms are appropriate for RTCWEB are here, not in TSV.

This results in my second request.

ACTION REQUEST 2: I request that the chairs declare that based on the
debate about the QoS functionality so far, the document should be
resurrected, and will continue to be  worked on in the RTCWEB working
group, bringing in advice from TSVWG as required to make sure the
descriptions of underlying mechanisms, and the choice of such
mechanisms, is correct and appropriate.

-- 
Surveillance is pervasive. Go Dark.

---

From: James Polk <[email-masked]>
Date: Wed, 13 Nov 2013 16:11:36 -0600

I, speaking at the mic, was merely pointing out that this draft had 
moved to TSVWG back in the Atlanta timeframe (though, thinking back, 
I think I left the timing piece out of my comment), so it wasn't a 
recent decision. I believe this came directly from talks between the 
above mentioned ADs.

As for RTCweb work being more appropriately inside the RTBweb WG 
instead of another group, I'd like to point out that much of the SDP 
work related to this WG is in fact being done in MMUSIC. Much of the 
RTP work being done by this WG is being done in AVTCORE (or AVTEXT?). 
All of the base SCTP work being done by this WG is being done in TSVWG.

(this is not an attack, but...)

...why are you arguing for something as far away down the stack as 
DSCP assignments to be done in RTCweb, and not where all other 
DiffServ work is being done in the IETF (in TSVWG)? Do you not trust 
that TSVWG will do an appropriate just with a DiffServ ID but you 
will trust TSVWG with SCTP IDs?

Color me confused...

James

BTW - Full disclosure, I'm an listed author of this draft, but had no 
voice in it getting moved between the WGs.

At 02:21 PM 11/13/2013, Harald Alvestrand wrote:
>_______________________________________________
>rtcweb mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 14 Nov 2013 03:16:40 +0100

On 11/13/2013 11:11 PM, James Polk wrote:
> moved to TSVWG back in the Atlanta timeframe (though, thinking back, I
> think I left the timing piece out of my comment), so it wasn't a

This only reinforces my procedural comment. The fact that the decision,
and the reasons for it, has been hidden from the group for 8 (?) months
only makes it worse, not better.

When ADs make decisions by talking among themselves, they have a special
duty to make sure those decisions are public and open to the community.
That duty has not been executed in this case.
I don't know who dropped the ball - the ADs or the chairs. But the ball
was definitely dropped.

> All of the base SCTP work being done by this WG is being done in TSVWG.

I have issues with those too. Especially the speed at which they're
progressing. But those decisions were made and announced in a timely
fashion.

The argument that has been used is that the pieces we need defined
(BUNDLE, MSID, circuit-breakers, RMCAT) have general applicability, and
should therefore be processed by groups that are chartered to define
extensions with general applicability.

> that TSVWG will do an appropriate just with a DiffServ ID but you will
> trust TSVWG with SCTP IDs?

My understanding of the QoS draft has always been that it should define
no new codepoints. It should point out the language we need to translate
RTCWEB requirements ("audio should go faster than video, except when the
app says that it should be the other way around") into already-defined
DSCP code points.

I have not seen anyone arguing for new DSCP codepoints, so I really
wonder what work there is for TSVWG to do.

Again, the arguments may be there, but since they were never exposed to
the mailing list, I cannot evaluate them.

> voice in it getting moved between the WGs.

My biggest practical issue with this draft is that it's functionally
dead. I'm getting put in a place where I have to either delay shipping
this feature in product or ship without even the guidance of a live draft.

I want this group to be done. As long as I can't even point to the
document that describes how we do QoS, I have no chance of getting it to
that stage.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 13 Nov 2013 20:29:19 -0800

> document that describes how we do QoS, I have no chance of getting it to

[BA] The approach of dispersing work among half a dozen WGs isn't working in this case, and in fact hasn't worked particularly well in the past either, because it generates neither urgency nor focus. 

At this point, we are probably not much more than a year away from widespread deployment of  running code. So if a critical dependency is not making progress toward a WGLC it is time to hit reset. The reality is that there is no reservoir of undiscovered manpower to get this work done, just interested authors and reviewers who if fed a steady stream of documents without unnecessary distractions and bureaucratic impediments can help us rapidly get to closure. 

Our current process is akin to shuttling children from one neglectful foster home to another until we lose track of them and realize to our dismay that something bad has happened. This isn't a plan so much as an accident waiting to happen.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Thu, 14 Nov 2013 05:21:13 +0000

I'm trying to not say much on this whole thread but I wonder if the tsv-ad could provide any more insight around why this was appropriate for TSV. 

It's not assigning any new DSCP, it's simply providing pointers to the existing codes defined in documents done by TSV that talk about the DSCP to use for audio, video, and such. I think if folks could help people understand what transport content was, that would help. (and added David as he has been involved with this draft ) 

Cullen in my individual contributor role.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 14 Nov 2013 00:33:00 -0600

On Wednesday, November 13, 2013, Cullen Jennings (fluffy) wrote:

>
> I'm trying to not say much on this whole thread but I wonder if the tsv-ad
> could provide any more insight around why this was appropriate for TSV.

Probably so, but Martin is on his last week of parental leave - I'll check
with him when he surfaces.

Spencer

>
> It's not assigning any new DSCP, it's simply providing pointers to the
> existing codes defined in documents done by TSV that talk about the DSCP to
> use for audio, video, and such. I think if folks could help people
> understand what transport content was, that would help. (and added David as
> he has been involved with this draft )
>
> > [BA] The approach of dispersing work among half a dozen WGs isn't
> working in this case, and in fact hasn't worked particularly well in the
> past either, because it generates neither urgency nor focus.
> >
> > At this point, we are probably not much more than a year away from
> widespread deployment of  running code. So if a critical dependency is not
> making progress toward a WGLC it is time to hit reset. The reality is that
> there is no reservoir of undiscovered manpower to get this work done, just
> interested authors and reviewers who if fed a steady stream of documents
> without unnecessary distractions and bureaucratic impediments can help us
> rapidly get to closure.
> >
> > Our current process is akin to shuttling children from one neglectful
> foster home to another until we lose track of them and realize to our
> dismay that something bad has happened. This isn't a plan so much as an
> accident waiting to happen.
> >
> >
> >
> >
> >>
> >>
> >>>
> >>>> My archive shows 36 messages w

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 14 Nov 2013 10:10:42 +0200

Hi Harald,

thanks for your email. I will touch base with the TSV ADs and with Wes
(former TSV AD) and get a status update on this piece of work. It will
take a few days, though (when Martin will be back, as Spencer also
mentioned in this thread). We will keep the group posted.

Cheers,

Gonzalo

---

From: Wesley Eddy <[email-masked]>
Date: Thu, 14 Nov 2013 12:19:43 -0500

> mentioned in this thread). We will keep the group posted.

I was mostly guilty for advocating that this be moved over, so
no need to bother Martin in order to explain the history.

It was creating some confusion between multiple WGs at the IETF
meeting, particularly with regard to what RMCAT was doing, what
RTCWEB was doing, and how DiffServ actually works.  So we had a
quick discussion about moving it to TSVWG between the available
set of:
- authors
- RTCWEB chairs
- TSVWG chairs
- RAI ADs
- TSV ADs

At the time that it was moved over to TSVWG, I had sent the
TSVWG a description of why:
http://www.ietf.org/mail-archive/web/tsvwg/current/msg11631.html

I agree that this obviously should have also been discussed in
the RTCWEB WG.  If all interested people weren't aware of the
move, then that is bad, and should be corrected now.

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

---

From: Ted Hardie <[email-masked]>
Date: Thu, 14 Nov 2013 10:38:12 -0800

> reference to it is not correct and is easy to fix.

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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 14 Nov 2013 21:27:38 +0200

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 <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> that shipping code does require this to be resolved.  The message you
> point to above notes a core issue, which I assume is this:
> 
> where in the document they should raise the issue or where there is work they can reference
> for incorporation?
>

---

From: James Polk <[email-masked]>
Date: Thu, 14 Nov 2013 13:31:11 -0600

>only makes it worse, not better.

it was mentioned during the chair's review of RTCweb documents during 
the Orlando RTCweb meeting. I was there in the front row...

>I don't know who dropped the ball - the ADs or the chairs. But the ball

I think this was announced on the list, but was part of a larger 
email, and not the main topic (i.e., "subject" line)... making 
searching for it difficult at best.

>progressing. But those decisions were made and announced in a timely

I figured this was part of the problem, and have nothing good to add here.

>extensions with general applicability.

it was RMCAT (also in Transport) that was the main interaction from 
my pov, and I think from the TSVWG chairs pov, as RMCAT's chairs said 
to TSVWG (paraphrasing) "we don't think we're going to need anything 
new or existing work wrt DiffServ to solve RMCAT's solution". This 
effective told the TSVWG chairs they could table/postpone/whatever 
the DiffServ draft from RTCweb until RMCAT was through deciding which 
solution they were going to go with. I think, perhaps, the TSVWG 
chairs (me included) thought there was more of a direct link between 
RMCAT and RTCweb than there really was. If there was, and we were 
talking past each other, then  apologize, as I clearly didn't get that memo.

>no new codepoints.

It shouldn't and doesn't, it's merely a profile doc for RTCweb (said 
as an author and as a TSVWG chair).

>It should point out the language we need to translate

that's my understanding (of the requirements) too

>I have not seen anyone arguing for new DSCP codepoints

nor should they have

>, so I really

to make sure that no one specifies anything stupid in the profile.

What RTCweb doesn't know, except for Magnus and Colin, is that TSVWG 
is in the process of bis-ing our DiffServ guidelines RFC (4594). 
We've reached WG consensus on most of the proposed changes, by the 
author/editor has a couple of changes he hasn't reach WG consensus with/on.

>the mailing list, I cannot evaluate them.

"never" is, I think, not true.

I'll give you 'announced along with 50m other things in RTCweb 
(buried in the background noise) ...

>dead.

see above for the confusion

>I'm getting put in a place where I have to either delay shipping

I can certainly appreciate that

>document that describes how we do QoS, I have no chance of getting it to

again, I can certainly appreciate that

James

---

From: Wesley Eddy <[email-masked]>
Date: Thu, 14 Nov 2013 15:18:50 -0500

On 11/14/2013 1:38 PM, Ted Hardie wrote:
> that shipping code does require this to be resolved.

Hi Ted, it probably doesn't matter if I don't understand, but
it seems dubious to me that any shipping code could be held
up over this.  Codebases don't need to set DSCP in the same
way, plus we've always been told that RTCWEB codebases are
easy to upgrade.  Anyone can ship code setting the DSCPs in
whatever way they want to, and there will be no interop issues.

> The message you
> ...

Actually, there are others.  It was pointed out on the TSVWG list
that the actual mappings recommended in the document are not going
to work well.  For instance, see:
http://www.ietf.org/mail-archive/web/tsvwg/current/msg12072.html

> as a clear enough signal that they were blocked on this.

I don't know if they're really "blocked" on this though ... I've
just brought it up as a comment.

> where in the document they should raise the issue or where there is work they can reference

IMO, this is a fundamental issue with the recommendation that
differs from the way that DiffServ is implemented and thought
about.  Classifiers operate based on flow-level n-tuple
information generally.  The document pretends that what it's
prescribing is perfectly normal, which I don't think is the case,
and I don't know if it's even something the IETF wants to do.

-- 
Wes Eddy
MTI Systems

---

From: "Subha Dhesikan (sdhesika)" <[email-masked]>
Date: Thu, 14 Nov 2013 20:54:30 +0000

Thanks Gonzalo.  I am sorry I am coming in late ...

- I was asked to move the document from RTCWEB to TSVWG and here is an email I posted to announce that it has moved in TSVWG. 
http://www.ietf.org/mail-archive/web/tsvwg/current/msg11609.html
It seems like I did not post a similar thread to RTCWEB.   

- I am aware that there are concerns regarding the draft due to the bundling of flows.  I did not update the draft for Vancouver because I was looking for the outcome or discussions regarding bundling in RTCWeb.  The update I am looking to provide (but will have discussions with people who have expressed this objection) is that this QoS draft will not get into bundling issues. The application will provide the priority, the suggestion of how to translate them into the DSCP value  or other values will be the focus of the draft.  
In the bundling discussion, Dan Drutta, co-author of this draft raised an issue that bundling should take priority into account. That viewpoint will continued to be expressed but outside this draft.

- The other reason that this draft was not updated is because we were waiting on the priority tags to be defined from the application to the browser. This was done recently in W3C. 

So, a new draft will go out by the end of the month. I would very much like to understand why/how this draft has caused a dependency on implementations. I am happy to work with other authors to remove any roadblocks this draft is causing.

Regards,
Subha

-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]] 
Sent: Thursday, November 14, 2013 11:28 AM
To: Ted Hardie
Cc: Wesley Eddy; Harald Alvestrand; [email-masked]; [email-masked]; [email-masked]; Subha Dhesikan (sdhesika)
Subject: Re: [rtcweb] Protesting the QoS document decision

Hi,

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:
> 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:
> 
> 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.
> 
> 
> work they can reference for incorporation?
> 
> other contexts, is a problem.  I'm kind of concerned as well that they 
> will take the simple solution (use the most stringent
>

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 14 Nov 2013 22:11:42 +0000

We don't need to keep hearing from people how much they want this done - 
we need to hear from people who say they'll do this, or speak to people 
who understand the issues and get new text to go into this draft.

The draft was discussed at length in Berlin. Cullen presented to TSVWG - 
it received feedback, comments, and a request to address the comments on 
the list or in the draft. We followed-up with announcement to RMCAT in 
Berlin, and a tiny bit of feedback. Cullen who presented, also Chairs 
RMCAT - so surely can't be "hidden" from RMCAT?

In TSVWG, there was interest recorded in doing such work, and there's 
surely expertise to work on DSCP-related issues. However, I saw no 
discussion following Berlin on the list or responses from the authors, 
sorry. We did see need for various other things (SCTP-related) by RMCAT, 
and promptly adopted and also prioritized these.

I hoped there would be an updated draft - but there was no presentation 
requested and there had been no document update in response to the 
comments. IF Cullen had wanted to come back and say more (or anyone 
else) they could have done.

If people *are* interested - and people keep saying they are - then 
please listen to the feedback being given and either update the draft or 
propose another draft that addresses the comments. If the comments don't 
apply for some reason, then bring up the topic on the list. If the 
feedback isn't clear enough to act upon, and it may not be after time, 
we can surely help...

We're listening...

Gorry
(wearing TSVWG chair hat)

On 14/11/2013 19:31, James Polk wrote:
> I think this was announced on the list, but was part of a larger email,
> and not the main topic (i.e., "subject" line)... making searching for it
> difficult at best.
>
> it was RMCAT (also in Transport) that was the main interaction from my
> pov, and I think from the TSVWG chairs pov, as RMCAT's chairs said to
> TSVWG (paraphrasing) "we don't think we're going to need anything new or
> existing work wrt DiffServ to solve RMCAT's solution". This effective
> told the TSVWG chairs they could table/postpone/whatever the DiffServ
> draft from RTCweb until RMCAT was through deciding which solution they
> were going to go with. I think, perhaps, the TSVWG chairs (me included)
> thought there was more of a direct link between RMCAT and RTCweb than
> there really was. If there was, and we were talking past each other,
> then  apologize, as I clearly didn't get that memo.
>
>
>> >
> It shouldn't and doesn't, it's merely a profile doc for RTCweb (said as
> an author and as a TSVWG chair).
>
> What RTCweb doesn't know, except for Magnus and Colin, is that TSVWG is
> in the process of bis-ing our DiffServ guidelines RFC (4594). We've
> reached WG consensus on most of the proposed changes, by the
> I'll give you 'announced along with 50m other things in RTCweb (buried
> in the background noise) ...
>
>
>> >
>> > Color me confused...
>> >
>> > James
>> >

---

From: "Eggert, Lars" <[email-masked]>
Date: Fri, 15 Nov 2013 08:51:45 +0000

> and I don't know if it's even something the IETF wants to do.

+1

This really needs some deep thinking by the DiffServ folks. (And they don't hang out in RTCWEB.)

Lars

---

From: "Eggert, Lars" <[email-masked]>
Date: Fri, 15 Nov 2013 08:52:44 +0000

s/RMCAT/RTCWEB/g

Otherwise, +1

On 2013-11-14, at 23:11, Gorry Fairhurst <[email-masked]> wrote:

> We don't need to keep hearing from people how much they want this done - we need to hear from people who say they'll do this, or speak to people who understand the issues and get new text to go into this draft.
> 
> The draft was discussed at length in Berlin. Cullen presented to TSVWG - it received feedback, comments, and a request to address the comments on the list or in the draft. We followed-up with announcement to RMCAT in Berlin, and a tiny bit of feedback. Cullen who presented, also Chairs RMCAT - so surely can't be "hidden" from RMCAT?
> 
> In TSVWG, there was interest recorded in doing such work, and there's surely expertise to work on DSCP-related issues. However, I saw no discussion following Berlin on the list or responses from the authors, sorry. We did see need for various other things (SCTP-related) by RMCAT, and promptly adopted and also prioritized these.
> 
> I hoped there would be an updated draft - but there was no presentation requested and there had been no document update in response to the comments. IF Cullen had wanted to come back and say more (or anyone else) they could have done.
> 
> If people *are* interested - and people keep saying they are - then please listen to the feedback being given and either update the draft or propose another draft that addresses the comments. If the comments don't apply for some reason, then bring up the topic on the list. If the feedback isn't clear enough to act upon, and it may not be after time, we can surely help...
> 
> We're listening...
> 
> Gorry