Subject: [tsvwg] confirming adoption of L4S drafts

From: Wesley Eddy <[email-masked]>
Date: Fri, 31 Mar 2017 10:08:10 -0400

Hello, this is a note to confirm that due to the positve response at the 
last couple IETF meetings and on the mailing list, and currently no 
negative responses, we (TSVWG co-chairs) think there's consensus to 
adopt the set of 3 L4S drafts.

https://tools.ietf.org/html/draft-briscoe-tsvwg-l4s-arch
https://tools.ietf.org/html/draft-briscoe-tsvwg-aqm-dualq-coupled
https://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-l4s-id

We've asked the authors to wait a week, just to confirm this with the 
mailing list, before submitting the documents as draft-ietf-tsvwg-...

Please don't hesitate to start reviewing and discussing the open items 
Koen highlighted yesterday.

---

From: Michael Welzl <[email-masked]>
Date: Fri, 31 Mar 2017 14:47:26 -0500

Hi all,

Sorry, I would have gone to the mic to say this yesterday, but time was running short, there were lots of others going there, AND I was scribing… hence now this email:

I’m a little worried that we’re adopting a behavior inside the network, without specifying how end systems should work with it. In particular, what makes me feel uneasy is slide 2 from yesterday’s presentation:
https://www.ietf.org/proceedings/98/slides/slides-98-tsvwg-sessb-l4s-drafts-01.pdf <https://www.ietf.org/proceedings/98/slides/slides-98-tsvwg-sessb-l4s-drafts-01.pdf>
which showed TCP Prague as an ICCRG item. I think this misrepresents the role of an IRTF group: yes ICCRG can publish documents, but these have an IRTF boilerplate, and I don’t think that’s the right way to publish an e2e counterpart to an IETF Experimental RFC. As I explained in tsvarea earlier this week:
https://www.ietf.org/proceedings/98/slides/slides-98-tsvarea-sessb-discussion-on-congestion-control-work-in-the-ietf-the-role-of-iccrg-michael-welzl-00.pdf <https://www.ietf.org/proceedings/98/slides/slides-98-tsvarea-sessb-discussion-on-congestion-control-work-in-the-ietf-the-role-of-iccrg-michael-welzl-00.pdf>
… the more common role of ICCRG is to pre-evaluate proposals before they’re even ready for the IETF.

Technically, these are not so minor issues. DCTCP, as it stands, doesn’t work on the Internet; there are Internet-specific problems that would first need to be addressed. Two cases were discussed yesterday:
1) how will this work when there are two bottlenecks in a row?
2) what if TCP Prague traffic gets into a “classic” ECN queue?
… and these are likely not the only ones. E.g., the second problem was identified long ago, at the L4S BoF - see slide 3:
https://www.ietf.org/proceedings/96/slides/slides-96-l4s-6.pdf <https://www.ietf.org/proceedings/96/slides/slides-96-l4s-6.pdf>
where it says "Fall-back to classic TCP on classic ECN bottleneck”. Worryingly, the “starting point” column says “none”, and so far it doesn’t seem that we have an answer to this question.
=> what will this do to the ongoing effort of Apple to enable (classic) ECN?

Cheers,
Michael

> On Mar 31, 2017, at 9:08 AM, Wesley Eddy <[email-masked]> wrote:
> 
> Hello, this is a note to confirm that due to the positve response at the last couple IETF meetings and on the mailing list, and currently no negative responses, we (TSVWG co-chairs) think there's consensus to adopt the set of 3 L4S drafts.
> 
> We've asked the authors to wait a week, just to confirm this with the mailing list, before submitting the documents as draft-ietf-tsvwg-...
> 
> Please don't hesitate to start reviewing and discussing the open items Koen highlighted yesterday.
> 
>