Re: [Last-Call] [tsvwg] Artart last call review of draft-ietf-tsvwg-l4s-arch-18
Bob Briscoe <ietf@bobbriscoe.net> Sun, 24 July 2022 19:38 UTC
Return-Path: <ietf@bobbriscoe.net>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE519C157B44; Sun, 24 Jul 2022 12:38:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00rLDj1m8l5Y; Sun, 24 Jul 2022 12:38:07 -0700 (PDT)
Received: from mail-ssdrsserver2.hostinginterface.eu (mail-ssdrsserver2.hostinginterface.eu [185.185.85.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 156CFC14CF1C; Sun, 24 Jul 2022 12:38:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=alTlTMR9Q0DLMH+v8uwLwniIF/ZQanAB6EiKUQQIqM8=; b=k7csS862LCm/2JJPUCWYI7WU9C IvD8VVWjTp5AWHaNH40xjnDwq2PEWXVQr3Z0rM5PUkzg68MLyVBUk8hu9f3+CbSs8baAwkyIIMHy3 W4pfOvUdiipdifyHPW50+jQrKZizavE0RsyFjfv9POjTOFH47r071Mql7j0dSeu5UNKKNcWAhvPXy ns6bhF8RdO/zKxuAc97XTiUVBO+1acMy2/ZI+FbDWdkmj8mU8xSE3blVCGvivpnMVGAHxpQJbJjRR Pf8JbIlMxobYHwR2TrS4dUNNlFEDgHeqn54a3oTBZn+wKLh2dYtahH6UZWB8LOw8R8xXRAaP15hlo v01hJhzw==;
Received: from dhcp-8852.meeting.ietf.org ([31.133.136.82]:38500) by ssdrsserver2.hostinginterface.eu with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.95) (envelope-from <ietf@bobbriscoe.net>) id 1oFhQR-0007Gk-Fm; Sun, 24 Jul 2022 20:38:04 +0100
Content-Type: multipart/alternative; boundary="------------b0wHQJFK5luegTPWImwW0Ovc"
Message-ID: <b72f6f08-a5ec-1516-89e7-bf1f4d881cf2@bobbriscoe.net>
Date: Sun, 24 Jul 2022 15:37:57 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0
Content-Language: en-GB
To: Marco Tiloca <marco.tiloca@ri.se>, art@ietf.org
Cc: draft-ietf-tsvwg-l4s-arch.all@ietf.org, last-call@ietf.org, tsvwg@ietf.org
References: <165833585200.45796.11505382548835211711@ietfa.amsl.com> <ba2ce8e6-20d9-1fe8-6cbc-bafdc691d684@bobbriscoe.net> <bcff608e-5621-38e8-91b9-20acde0c3f23@ri.se>
From: Bob Briscoe <ietf@bobbriscoe.net>
In-Reply-To: <bcff608e-5621-38e8-91b9-20acde0c3f23@ri.se>
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - ssdrsserver2.hostinginterface.eu
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: ssdrsserver2.hostinginterface.eu: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: ssdrsserver2.hostinginterface.eu: in@bobbriscoe.net
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/GJAprfRhXs140o-DmBGuvl6ll1Q>
Subject: Re: [Last-Call] [tsvwg] Artart last call review of draft-ietf-tsvwg-l4s-arch-18
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 24 Jul 2022 19:38:11 -0000
Marco, OK. Thank you again. All items done. Bob On 24/07/2022 20:18, Marco Tiloca wrote: > Hi Bob, > > Thanks for your replies! Please see inline. > > Best, > /Marco > > On 2022-07-24 14:03, Bob Briscoe wrote: >> Marco, >> >> Thank you for taking the time to review the whole document with fresh >> eyes - much appreciated. >> We've taken all your points. In a couple of places, we modified a >> little - see [BB] inline. >> >> >> On 20/07/2022 17:50, Marco Tiloca via Datatracker wrote: >>> Reviewer: Marco Tiloca >>> Review result: Ready with Nits >>> >>> Thanks for this document! Please see my comments below. >>> >>> Best, >>> /Marco >>> >>> [General] >>> >>> * Based on the guidelines from RFC 7322, the "Acknowledgements" section should >>> be unnumbered and placed between the "References" section and the "Authors' >>> Addresses" section. >>> >>> * It is worth mentioning upfront that "capacity" refers to "link capacity" in >>> terms of experienced bit rate. This becomes explicit only in Section 5.1, when >>> discussing "Scalable throughput." >> >> [BB] This is useful feedback. >> >> We've substituted /capacity/link capacity/. >> >> Because we in the transport area 'capacity' every day. So, to better >> understand the comprehension problem, can I ask what you thought >> 'capacity' meant otherwise? > > ==>MT > Honestly, common sense does suggest "capacity" to be referred to > experienced bit rate over the link. > > But until I saw that confirmed in Section 5.1, I wondered: i) if > "capacity" could (also) refer to, e.g., session establishment rate, > maximum number of users/sessions that can be afforded etc. ; and ii) > what "capacity" was applied to, i.e., a link, a network segment, a > pool of network resources, etc. > > I think that using "link capacity" should be good and clear enough now :-) > <== > >> Do you want capacity explained in the terminology list? > > ==>MT > No; at least from my point of view, I don't see that as necessary. > <== > >> >>> [Abstract] >>> >>> * The three components of the L4S architecture include "protocol features that >>> allow network elements to identify L4S traffic". >>> >>> The protocol in question becomes evident in Section 2 as ECN. The abstract >>> can already mention that, e.g., as "features of the Explicit Congestion >>> Notification (ECN) protocol that allow ..." >> >> [BB] I've done this differently, 'cos I can see your point that many >> folks will just want to know what this protocol is, but shoe-horning >> it into this sentence adds distraction to what was meant to be a >> quick 1,2,3. So, I propose to add the last sentence below. It makes >> the already-slightly-long abstract slightly longer, but...: >> >> The L4S architecture consists of three components: network >> support to isolate L4S traffic from classic traffic; protocol >> features that allow network elements to identify L4S traffic; and >> host support for L4S congestion controls. *The protocol is >> defined separately as an experimental change to Explicit >> Congestion Notification (ECN).* >> >> > > ==>MT > Looks good. > <== > >>> [Section 1] >>> >>> * "With some transport protocols, namely TCP and SCTP, the sender has to check >>> for suitably updated receiver feedback, whereas with more recent transport >>> protocols such as QUIC and DCCP, all receivers have always been suitable." >>> >>> The first part of the sentence focuses on checking feedback from receivers, >>> while the second one on the actual receivers. Does the second part actually >>> mean "... feedback from all receivers is always suitable" ? >> >> [BB] There's a zero-RTT handshake negotiation with the receiver, so >> one could say that the sender doesn't actually check the feedback, it >> checks what feedback the receiver says it supports. But the handshake >> is encoded into the feedback, so it's hard to draw a line between >> receiver and feedback. Whatever, how about this (I've changed yours >> to the past imperfect): >> >> With some transport protocols, namely TCP and SCTP, the sender has to check >> for suitably updated receiver feedback, whereas with more recent transport >> protocols such as QUIC and DCCP,*feedback from* receivers*has* always been suitable. >> >> > > ==>MT > Looks good. > <== > >>> [Section 2] >>> >>> * "... as the protocol to identify to the network which packets are L4S and >>> which are Classic." >>> >>> This should be something like "... as the protocol that allows the network >>> to identify which packets are L4S and which are Classic." >> >> [BB] Yup >> >>> [Section 5.2] >>> >>> * "... as opposed to TLS over UDP" >>> >>> Do you mean "TLS over TCP" or rather "DTLS over UDP"? Or instead the use of >>> TLS for securing UDP-based transports such as QUIC? >> >> [BB] DTLS >> >>> [Nits] >>> >>> * Section 3: s/low enough not build/low enough to not build >>> >>> * Section 4.3: s/specifies that requirements that/specifies the requirements >>> that >>> >>> * Section 5.1: s/because it assume/because it assumes >> >> [BB] Got all these. >> >> Thank you. >> >> >> >> Bob >> >> >> >> -- >> ________________________________________________________________ >> Bob Briscoehttp://bobbriscoe.net/ > > -- > Marco Tiloca > Ph.D., Senior Researcher > > Phone: +46 (0)70 60 46 501 > > RISE Research Institutes of Sweden AB > Box 1263 > 164 29 Kista (Sweden) > > Division: Digital Systems > Department: Computer Science > Unit: Cybersecurity > > https://www.ri.se -- ________________________________________________________________ Bob Briscoehttp://bobbriscoe.net/
- [Last-Call] Artart last call review of draft-ietf… Marco Tiloca via Datatracker
- Re: [Last-Call] [art] Artart last call review of … Anjam Saqib
- Re: [Last-Call] [tsvwg] Artart last call review o… Bob Briscoe
- Re: [Last-Call] [tsvwg] Artart last call review o… Marco Tiloca
- Re: [Last-Call] [tsvwg] Artart last call review o… Bob Briscoe