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

Yoshifumi Nishida <> Tue, 09 February 2021 07:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 94DF33A1209 for <>; Mon, 8 Feb 2021 23:16:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, 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 K8cBCJ21w-_K for <>; Mon, 8 Feb 2021 23:16:27 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::72a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0BD783A11E8 for <>; Mon, 8 Feb 2021 23:16:26 -0800 (PST)
Received: by with SMTP id r77so17051057qka.12 for <>; Mon, 08 Feb 2021 23:16:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=J6Wuc0Kptd0c7ig+gdXnJPRS3BtpvUmD43INXsvjC6c=; b=gfK1rwNVJjva2Jms+iHJXamwqIo7MIJWJCOw0EbsH5mYhKAz6v3Gn2HWhNf/AzSrw4 i8zHRTSni0WvgVF0n5SiGw3TI9Ohq0quBduB7FHfYV63gSO7GCc+DLag30V1rQWXdak3 hzqbcKBd5ZxAy5CM2mDku+d3NEEV4zKrY6STrdf+D0QBNw2s0gLshK8FU19pFqRESdGI qiFiOS5yHWqy7DWLjzEgB0C/lZcSbO52T/OMmohSOmF018EDgp28c0UZXIkBiX2iw1O2 fh6HKi1p2OfBiKwWHJYr+WML2yQzX2cFquZcDkufy6eoJ3eKpyEDBxkWDkIriq5jgMQd DVbQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=J6Wuc0Kptd0c7ig+gdXnJPRS3BtpvUmD43INXsvjC6c=; b=Zg1hDx5dT0pC/JX0OmIZ79byosbCR2D/JEj6a3UrMMSDDSrIC/CSyCJ0d7CBrTkFSK KEgZ09JGR2Isz4dqYBSuEJeX3gAH8OUYZxLAPUvb3v3DB4gU/OlDq0vkwhtkv4XwfgAk AfUqfAPfiJ6Wbs0fnmJ6AGCXm/qeN6PTTzABa76+eg4ILvNJ9eSMD3WI6bWBVBduUEZV 6iiac7LNn/V2IvE/eakfpyeGLAtiRxmedQos9hjw7CBVoRwlVbiko+3twg++46kMvRah 1b99jL9ZwKHt8vquCdLU29dndQHJvGpG1nU6sRBnht+4bKDecj/7zc4rbeRYRQv1DEx5 PD5w==
X-Gm-Message-State: AOAM5338NqJTJW2XA3lInpqU8XGOJyVpOJbg62RVMdP85oxQwOxTdq0Y h9SZXLQjAfNNrCX3GElv0plfnjKSd7KPKIBQB3A=
X-Google-Smtp-Source: ABdhPJxLKymtUv6Evaiv1/IxqB3L7CGahlNLeianewQ7ozmyvi89Nhoj7q4thA6CN9bFwk9fPoNQRLQBBW6ZwqHv6do=
X-Received: by 2002:a05:620a:745:: with SMTP id i5mr21020510qki.321.1612854986043; Mon, 08 Feb 2021 23:16:26 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Yoshifumi Nishida <>
Date: Mon, 08 Feb 2021 23:16:14 -0800
Message-ID: <>
To: "Scheffenegger, Richard" <>
Cc: Matthew Luckie <>, " Extensions" <>
Content-Type: multipart/alternative; boundary="00000000000084736005bae21080"
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: Tue, 09 Feb 2021 07:16:36 -0000

Hi Richard,

On Mon, Feb 8, 2021 at 2:49 PM Scheffenegger, Richard <>

> Thanks!
> Still, without additional constraints my simplistic reading of how the
> GID value mapping to groups doesn't seem to address such collisions
> entirely..
> Also, some options are not necessarily negotiated, but only indicated -
> thus a constraint that corresponding bits of the group may only be set
> in a <SYN,ACK>, when they where present in the <SYN> is not sufficient.
> One constraint I could come up with would be to require  the server to
> reflect back "empty" (all zero option flags) blocks received from the
> client, in case a bitstream collision would otherwise happen
> e.g. client wants to signal option flag 7 of group 2, while server wants
> to send back option flag 7 of group 1 (but not flag 7 of group 2), the
> current draft would allow a "valid" exchange that looks like a reflection.
> With the above, additional constraint, the server would have to return
> an all-zero block for group 2 also, and may NOT skip over that...

I see your points. Thanks for pointing out an interesting case.

In such case, I might want to use the extension block (GID=3 in SYN, GID=0
in SYN/ACK) defined in the draft.
If server wants to send group IDs that didn't exist in the agg option in
SYN, it needs to attach an extension block as well.

So, in your case, sender sends back GID=1 with flag 7 and GID=3 with a
certain bit on (TBD).
I think this can be used as a proof that this is not a reflection.