Re: [tcpm] I-D Action: draft-nishida-tcpm-agg-syn-ext-00.txt

Joseph Touch <> Sat, 13 February 2021 04:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3BF213A0D4A for <>; Fri, 12 Feb 2021 20:45:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xPGTltC2KUNG for <>; Fri, 12 Feb 2021 20:45:04 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B37D03A0D48 for <>; Fri, 12 Feb 2021 20:45:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version: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=LkGT/LOKs1q28F82018CjPpRQaC/E0OweRYPMfMKnWM=; b=AazxhrXBl5gzc3VbaYG35exnW CMISMIcGzMm0XwtDm9QQm8LTRYRtNXkM23HeBbDK52JskS7RbWIFX/zAVsExpFJoTXKp6G1cXuqfb RDe0PlZn4rEh7YQ6NS49684WZeKUN3532x4TmjMs14SuXQAU02tisSSQJ35IOCBegqGFrJWEUzP/J NsFJB4UWyuwSjc5ltokJcZwtFt7fvuuZ/g5k1WbQ4avmjpojF/A3kCVkB61dorjbvZcs/33I0eToH UdfWQpSxZ2OXkCpjUm2fhxXOgDQIslANM5OkZ+s9+eO8Ex4Nm6cleN1PMSc59hSwGJ+MF9Ag+TEta ulPtGIwyQ==;
Received: from ([]:64041 helo=[]) by with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from <>) id 1lAmnf-000z4y-1g; Fri, 12 Feb 2021 23:45:00 -0500
Content-Type: multipart/alternative; boundary="Apple-Mail=_72F1FAC9-4960-49FE-B38E-0A24B95FFBA3"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
From: Joseph Touch <>
In-Reply-To: <>
Date: Fri, 12 Feb 2021 20:44:54 -0800
Cc: " Extensions" <>, Liangqiandeng <>
Message-Id: <>
References: <> <> <> <> <> <> <> <>
To: Yoshifumi Nishida <>
X-Mailer: Apple Mail (2.3654.
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
X-From-Rewrite: unmodified, already matched
Archived-At: <>
Subject: Re: [tcpm] I-D Action: draft-nishida-tcpm-agg-syn-ext-00.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 13 Feb 2021 04:45:06 -0000

> On Feb 12, 2021, at 9:52 AM, Yoshifumi Nishida <> wrote:
> OK. So, in my understanding, what you're suggesting are the followings.
> - Aggregated options would be useful. but, the format can be simple 4 bytes length option that can accomodate 16 options.


> - The tricks to avoid reflecting options in SYN ACK will not be needed because it's the receiver's responsibility.


> - Delayed negotiation might be possible. But, no generic framework is needed. Each option should be designed for its own way to support it.


> But, once thing I am wondering is that we can still combine Aggregated options and delayed negotiation even with this one.

Delayed negotiation is a completely separate and very complicated issue. It’s not as simple as “do it later”; in the TWHS, the sequence of messages is defined. Elsewhere, messages can come out of order - at which point the meaning of options with respect to that order has to be defined. That’s a can of worms and completely independent of whether aggregated options are supported.

> if you are meaning options not appeared in SYN cannot be used in the following segments, I think accecn option might be a precedent for this.  

Accecn may not appear in an option explicitly, but it is communicated using SYN flags. That’s very close to what the compressed options achieves.

I.e., the option value itself need not appear in the SYN, but the use of that option *is* signaled using the SYN/SYN-ACK, either way.

Again, doing that negotiaton after the TWHS is a separate and more complex issue that I believe should be defined for each option (even if you want to define it for a separate post-SYN aggregate option); it can’t be generalized for existing options.