Subject: [tsvwg] Draft TSVWG minutes from the meetings in Montreal

From: Gorry Fairhurst <[email-masked]>
Date: Sat, 10 Aug 2019 08:46:50 +0100

The Chairs have uploaded draft notes from the meetings to the materials.

https://datatracker.ietf.org/meeting/105/materials/minutes-105-tsvwg-03

Please let us know if there are any factual errors in the notes or 
corrections to names, etc. Thanks again to the volunteers who helped 
take these notes!

Gorry, Wes and David

---

From: Jonathan Morton <[email-masked]>
Date: Sat, 10 Aug 2019 11:22:09 +0300

> On 10 Aug, 2019, at 10:46 am, Gorry Fairhurst <[email-masked]> wrote:
> 
> Please let us know if there are any factual errors in the notes or corrections to names, etc. Thanks again to the volunteers who helped take these notes!

I have a few proposed corrections:

> Jonathan Morton: I have 4 topics:
> f) IETF approval is required to use ECN.  
> g) Incremental deployment requires compatibility, which has not been demonstrated so far.
> a) Effective congestion control is required. FQ_Codel is the most deployed AQM. With the current Codel, the time to reach the correct marked rate would be 4 seconds (?). 4 seconds for a link with 10ms is not effective.
> b) Fair queueing is fairly robust. My concern is when there are two consecutive bottlenecks. In our experiments we have found issues.

Referring to the notes I was reading from:

Under point F, I was not referring to ECN use in general - that would be absurd as it's a current RFC - but to the Congestion Response/Marking Differences experiments provided for in RFC-8311, due to the effective redefinition of the CE codepoint proposed by L4S.

Under point A, I was referring to Codel in general, not FQ-Codel, although most actual deployments of Codel are indeed as part of FQ-Codel.  The inadequate response of DCTCP (and thus presumably Prague) to Codel is of only slightly less concern in FQ form, due to the consecutive-bottleneck problem alluded to in point B (where the upstream bottleneck may be a dumb FIFO).

The following would better capture the above:

f) IETF approval is required for ECN semantic changes, even under RFC-8311.
[...]
a) Effective congestion control is required. Codel is the most deployed AQM.  (etc.)

> Wes: Does anyone want to bring up IPR?
> Rod: There are people who want to speak to IPR are not present.
> Jonathan: Dave Taht wants to speak to this later, he could not join.
> Chairs: Please read the IPR summary and decide on your own position.

Here, the name I mentioned was Toke Hoiland-Jorgensen, not Dave Taht.  I'm sure Dave also has much to say on the subject, but it was Toke who had specifically said he wanted to comment that day.

 - Jonathan Morton

---

From: Dave Taht <[email-masked]>
Date: Sat, 10 Aug 2019 09:39:19 -0700

Jonathan Morton <[email-masked]> writes:

>> Please let us know if there are any factual errors in the notes or corrections
>> to names, etc. Thanks again to the volunteers who helped take these notes!
>
>> a) Effective congestion control is required. FQ_Codel is the most deployed
>> AQM. With the current Codel, the time to reach the correct marked rate would
>> be 4 seconds (?). 4 seconds for a link with 10ms is not effective.
>> b) Fair queueing is fairly robust. My concern is when there are two
>> consecutive bottlenecks. In our experiments we have found issues.
>
> Under point F, I was not referring to ECN use in general - that would be absurd
> as it's a current RFC - but to the Congestion Response/Marking Differences
> experiments provided for in RFC-8311, due to the effective redefinition of the
> CE codepoint proposed by L4S.
>
> Under point A, I was referring to Codel in general, not FQ-Codel, although most
> actual deployments of Codel are indeed as part of FQ-Codel.  The inadequate
> response of DCTCP (and thus presumably Prague) to Codel is of only slightly less
> concern in FQ form, due to the consecutive-bottleneck problem alluded to in
> point B (where the upstream bottleneck may be a dumb FIFO).

> Here, the name I mentioned was Toke Hoiland-Jorgensen, not Dave Taht.  I'm sure
> Dave also has much to say on the subject, but it was Toke who had specifically
> said he wanted to comment that day.

I've said my piece here, actually. It's in the hands of the lawyers now,
fronted by toke.