Re: [tcpm] Lars Eggert's Discuss on draft-ietf-tcpm-2140bis-10: (with DISCUSS and COMMENT)

Joseph Touch <touch@strayalpha.com> Thu, 25 March 2021 21:21 UTC

Return-Path: <touch@strayalpha.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36E5E3A0835; Thu, 25 Mar 2021 14:21:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.198
X-Spam-Level: *
X-Spam-Status: No, score=1.198 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, HAS_X_OUTGOING_SPAM_STAT=2.517, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com
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 796TBR6zaZ97; Thu, 25 Mar 2021 14:21:51 -0700 (PDT)
Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (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 35B813A0812; Thu, 25 Mar 2021 14:21:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To: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=XFl5ONYexnS2pAuNky7tIG5sE98fS3eXFP6m8FnnhDk=; b=ueSh+GA95u94ZqAKah+HyTF7V /AOGNByRDXfoZjn6OXA/jaH7tJUdIgCzcf8AhNNpEEVTCWbkPaBTNgoMwY36rlg5/aRUp66sEvKqd yI6sCV7/A3TFrHewhjwf3u2X4/yIeuJ7ruuaD9vGUimsGbYyV3l/K+yFPXy8sp8jwtgyW5EBq/o+T r5Sk+6J7AyOpNLFS7/A8JIF7uox41uJMnT499YJwfQY9AQTTutg+N7ZI2G3dz3X+Zdf97Jxo5nkVS l56IZv52F21oseB3aUlT7Ufq6B7e4QI1Hue4fc85xEIYbG7o/OGUSL8U1L1izSc2rO8C8rqmD9/bz 3vsjUwpAA==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:63080 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from <touch@strayalpha.com>) id 1lPXQI-003Qcz-Hy; Thu, 25 Mar 2021 17:21:50 -0400
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
From: Joseph Touch <touch@strayalpha.com>
In-Reply-To: <161666423177.6408.1029658445364068197@ietfa.amsl.com>
Date: Thu, 25 Mar 2021 14:21:43 -0700
Cc: The IESG <iesg@ietf.org>, tcpm IETF list <tcpm@ietf.org>, draft-ietf-tcpm-2140bis@ietf.org, tcpm-chairs@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <92DFC0A5-9095-49BB-87EC-685A5B854983@strayalpha.com>
References: <161666423177.6408.1029658445364068197@ietfa.amsl.com>
To: Lars Eggert <lars@eggert.org>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
X-OutGoing-Spam-Status: No, score=-0.2
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/C65NBdJErzQWcG85A8-Ut0QIjyo>
Subject: Re: [tcpm] Lars Eggert's Discuss on draft-ietf-tcpm-2140bis-10: (with DISCUSS and COMMENT)
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Mar 2021 21:21:56 -0000

Hi, Lars,

Thanks for the comments. 

Most will be included in the update, but I want to address two below briefly:

> On Mar 25, 2021, at 2:23 AM, Lars Eggert via Datatracker <noreply@ietf.org> wrote:
> 
> ...
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> "Appendix C", paragraph 1, discuss:
>> Appendix C: Automating the Initial Window in TCP over Long Timescales
> 
> The content of this appendix seems to be unrelated to TCB sharing and reads like
> a separate document - why is it included in this document?

Appendix C is TCB temporal sharing aggregated over long timescales and many endpoints to overcome the repeated need to statically update TCP’s IW. The intro there will be updated to make this much more explicit.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Paragraph 5, comment:
>>   This document may contain material from IETF Documents or IETF
>>   Contributions published or made publicly available before November
>>   10, 2008. The person(s) controlling the copyright in some of this
>>   material may not have granted the IETF Trust the right to allow
>>   modifications of such material outside the IETF Standards Process.
> 
> Joe, you were the single author of RFC2140. Would you grant BCP78 rights in
> RFC2140 to the IETF Trust?

I have been asked this before and declined. My position has not changed, so the boilerplate needs to remain.

> In that case, we don't need to keep the special
> pre-RFC5378 boilerplate.
> 
> Section 1, paragraph 2, comment:
>>   across connections to the same host [RFC2140]. Such sharing is
>>   intended to lead to better overall transient performance, especially
>>   for numerous short-lived and simultaneous connections, as often used
>>   in the World-Wide Web [Be94][Br02]. This sharing of state is
> 
> The modern web is using a lot fewer parallel connections compared to the web at
> the time RFC 2140 was written. So the example is slightly dated.

Can you clarify? All modern browsers are configured to allow 8-10 parallel connections, which is actually higher than when 2140 was written (it was half that).

> Section 9.1, paragraph 1, comment:
>> 9.1. Layering
> 
> The first paragraph in this section says "RTT information is better handled at
> the network layer", the second paragraph says "there are problems with handling
> RTT information at the network later" - which is it?

The latter; the former should say “is better informed by the transport layer but aggregated across connections. The latter is typically performed a the network layer but there are problems...”. 
(I’ll clean that up to be more clear).

> -------------------------------------------------------------------------------
> Section 7.1, paragraph 11, nit:
>>                sum(old_sendcwnd)   f(sum(old_sendcwnd), N)
>> _
>>                old_option          (option specific)
> 
> Why is there a dash here?

It’s just a typo.

(The rest of the diffs will be incorporated)

Joe