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

Dave Taht <dave@taht.net> Sat, 10 August 2019 16:39 UTC

Return-Path: <dave@taht.net>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C79CB120111 for <tsvwg@ietfa.amsl.com>; Sat, 10 Aug 2019 09:39:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OvX-vIGn1S3R for <tsvwg@ietfa.amsl.com>; Sat, 10 Aug 2019 09:39:38 -0700 (PDT)
Received: from mail.taht.net (mail.taht.net [176.58.107.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD60B120090 for <tsvwg@ietf.org>; Sat, 10 Aug 2019 09:39:38 -0700 (PDT)
Received: from nemesis.taht.net (unknown [172.58.92.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id EBD6421425; Sat, 10 Aug 2019 16:39:34 +0000 (UTC)
From: Dave Taht <dave@taht.net>
To: Jonathan Morton <chromatix99@gmail.com>
Cc: gorry@erg.abdn.ac.uk, "tsvwg@ietf.org" <tsvwg@ietf.org>
References: <5D4E766A.6000107@erg.abdn.ac.uk> <C079902E-8347-4F2A-8C2A-8C840F0847D0@gmail.com>
Date: Sat, 10 Aug 2019 09:39:19 -0700
In-Reply-To: <C079902E-8347-4F2A-8C2A-8C840F0847D0@gmail.com> (Jonathan Morton's message of "Sat, 10 Aug 2019 11:22:09 +0300")
Message-ID: <87h86pf008.fsf@nemesis.taht.net>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/d34IafeGIhvROU0EaQJxLcpLEQw>
Subject: Re: [tsvwg] Draft TSVWG minutes from the meetings in Montreal
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Aug 2019 16:39:41 -0000

Jonathan Morton <chromatix99@gmail.com> writes:

>> On 10 Aug, 2019, at 10:46 am, Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
>> 
>> 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!
>
> 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.

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

>
>  - Jonathan Morton