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
- [tsvwg] Draft TSVWG minutes from the meetings in … Gorry Fairhurst
- Re: [tsvwg] Draft TSVWG minutes from the meetings… Jonathan Morton
- Re: [tsvwg] Draft TSVWG minutes from the meetings… Dave Taht