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

Yoshifumi Nishida <nsd.ietf@gmail.com> Fri, 05 February 2021 06:51 UTC

Return-Path: <nsd.ietf@gmail.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 5A3E93A1CB3 for <tcpm@ietfa.amsl.com>; Thu, 4 Feb 2021 22:51:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 2alIFImET_1Q for <tcpm@ietfa.amsl.com>; Thu, 4 Feb 2021 22:51:08 -0800 (PST)
Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C16F3A1CB2 for <tcpm@ietf.org>; Thu, 4 Feb 2021 22:51:08 -0800 (PST)
Received: by mail-qt1-x82e.google.com with SMTP id h16so4281779qth.11 for <tcpm@ietf.org>; Thu, 04 Feb 2021 22:51:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qqYmpMfhm3A0hyoVJlHPOlmB90vDQVzxVDthrnxW988=; b=miyFpUb4+Ux/ocDJez/EHCo/8TesYIZ7ryhg2lrUn7RZuKBXQffaDek08kz+HfMetW G+MCqTB96MCplo5SSt/KtBJ2HWic4Yp24v5p+TKwufIG123a8YKUwyyeYxVfQt9ArvI5 f87bWwKZik6rZbMwtwm2Um0SAMmiNkseSeUiAEZyYluPnTSGq00TWPEYHAuZ9sIUg6kW ZxV3HYsCpZfXU+j+cZSPxoo94Gw0/CGgleqzr0m/0j853+szQlTr9mdNUDBdm58bJQAp tl3DzsT534fFE2EbBvdHIaqjnVA6I2MQsuBCM3vtYGN2cUx/NPNt6ORugFX3UhMQsqVd 1iSg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qqYmpMfhm3A0hyoVJlHPOlmB90vDQVzxVDthrnxW988=; b=iO2nYQeD6Bv0S9hEa/UCJ0lHY5tT67UScm2UoOJwLjXpL7P0iFCnYDj1cCaKEs9pBe OXaaWAb+nbjr1nJ9h83DS12gZp4jKrJw4Ie5jP7IGLn0VeLOxXwo+Vj0QpiZu+rbDxsA HfAaxY1zxlZDmkM8K5dZsMjhkci8BBPpqBwRwTZ5ynWUWNTtC+SbVCbwZS9TL+hMM/+s 9ZZ6fWG9j2VM41SXklDMYJ7oz6oQ/hhyOvDTD2u6wgBBiNO0JzSRR8w8V9Oit9u95kWu hI+/mnZPMVJVzMT8D8+s1AYL4e066++nfgXWYEEInTaAgsZBi1igH6TufiUf6BSPq9r/ L7iw==
X-Gm-Message-State: AOAM530bK20dRZJ/zcwUAB00KwL80EAvh1EbTIlck8Aqi/7r3gcW+Nhf U/xAjxlqb5u9A82UL6iS6e7ME/HriMNWG8+RJGY=
X-Google-Smtp-Source: ABdhPJxuU/JBaNpPdKQ5HyVROGgHAErYUSINH4WFBtidp8wnSyPNvia7+6NOCFIPzFhUycza4OayV+fneLkM09p9FC4=
X-Received: by 2002:ac8:1184:: with SMTP id d4mr2986486qtj.103.1612507867009; Thu, 04 Feb 2021 22:51:07 -0800 (PST)
MIME-Version: 1.0
References: <161233469809.31214.294457730576935197@ietfa.amsl.com> <CAAK044QYBiGXKm+D+=edc8TWhjzAadBxER5VRFmJOdW8hdXFKg@mail.gmail.com> <244FE3E7-7B83-4884-B11B-028F7167B549@strayalpha.com> <CAAK044RKtJ_PpDXH9pmS90wqUZNK9unDggiDjVLUBK00cxhYnA@mail.gmail.com> <8C6762C8-2A22-4CC7-AF53-1D13FC3DC268@strayalpha.com> <C591EED6-210A-4AEB-94D6-D3B77130596E@strayalpha.com>
In-Reply-To: <C591EED6-210A-4AEB-94D6-D3B77130596E@strayalpha.com>
From: Yoshifumi Nishida <nsd.ietf@gmail.com>
Date: Thu, 04 Feb 2021 22:50:55 -0800
Message-ID: <CAAK044SxMF1p-BzyOYWYkhYYrToLg+8Ybx8ZB-GeADGkayexGQ@mail.gmail.com>
To: Joseph Touch <touch@strayalpha.com>
Cc: "tcpm@ietf.org Extensions" <tcpm@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009c55d305ba913e8f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/Kgj5rQiFnRrvMNOiICZwBM_b7oQ>
Subject: Re: [tcpm] I-D Action: draft-nishida-tcpm-agg-syn-ext-00.txt
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: Fri, 05 Feb 2021 06:51:12 -0000

Hi Joe,

On Thu, Feb 4, 2021 at 12:35 PM Joseph Touch <touch@strayalpha.com> wrote:

> FWIW, I would have called this more “delayed option negotiation” than its
> current title.
>

OK. It seems it makes sense. Thanks for the suggestion. I will think about
updating the title.
I also would like to hear from people if there're other thoughts.


> The core issue as I see it is atomicity of options; there are many options
> that interact with others that cannot be delayed this way. And if option
> negotiation is delayed, the issue of what to do with data in the meantime.
>
> So overall, it could be a generally useful addition, but is quite distinct
> in capability and impact on both options and TCP than the previous
> attempted solutions.
>

I basically agree with you here.
In my view, the previous approaches such as yours try to provide complete
solutions to SYN option space, which can lead to very long discussions from
my observations.
Instead, the draft tries to provide a solution that has several
limitations, but it can reduce complexity and the risk of middlebox issues.
Also, we have similar precedence for this approach.

The main focus of the draft is to support newly defined options rather than
existing options. Especially, the ones that use EXID as they tend to
consume more space.
One of my concerns is scarce SYN option space discourages people from
developing and using new features.

As you mentioned, some options are difficult to be delayed. Section 5.3
describes this limitation and explains that TFO or AO cannot be supported
with this.
But, I think this approach is still useful as some options will not be
affected even though the negotiations are delayed a bit.
For example, if you want to send special feedbacks on some events by using
a certain options, you don't need to hold data transfer for the feature.
Or, in some cases, delays can be acceptable in order to use new features.

Thanks,
--
Yoshi



>
> On Feb 4, 2021, at 12:07 PM, Joseph Touch <touch@strayalpha.com> wrote:
>
> Hi, Yoshifumi,
>
> On Feb 3, 2021, at 11:02 PM, Yoshifumi Nishida <nsd.ietf@gmail.com> wrote:
>
> Hi Joe,
>
> Thanks for reading the draft. I put my comments in lines.
>
> On Wed, Feb 3, 2021 at 4:46 PM Joseph Touch <touch@strayalpha.com> wrote:
>
>> Hi, Yoshi,
>>
>> On Feb 2, 2021, at 11:12 PM, Yoshifumi Nishida <nsd.ietf@gmail.com>
>> wrote:
>>
>> Hi folks,
>>
>> I prepared a draft for SYN option space extensions.
>> I know this is a difficult issue in TCP and has been discussed for a long
>> time.
>> But, I'm thinking that it might be a good time to discuss it again.
>>
>>
>> The proposal has two parts, which are (AFAICT) separable:
>> A. Aggregated options
>> B. Adding more option space in the 3rd packet of a 3WHS
>>
>
> Right. both can be used supplementarily.
>
>
>> (A) is fine, although the most significant issue is legacy interaction.
>>
>> (B) is no longer extending the SYN; it’s actually just post-SYN
>> activation of new options.
>>
>
> In my view, all options are negotiated during SYN exchange. There's no
> post SYN activation.
> They are just additional information for the features already negotiated
> during SYN exchanges.
>
>
> I disagree; you’re suggesting putting NEW options in packets that don’t
> have a SYN. In that sense, it’s similar to my proposal, which uses a
> segment with no SYN and no ACK bit (the out-of-band segment).
>
> However, the problem is with the first SYN-ACK you send back. That is
> typically a confirmation of all options supported so the rest of the
> connection can commence, even for MPTCP. In your case, the exchange
> continues. This not only adds multiple RTTs to the open, it interferes with
> data sent in the SYN, data sent with the SYN-ACK, and fast-open for sure;
> it could also be a problem with many other options that don’t make sense in
> subsequent segments due to the way they need to coordinate info that is
> used in the SYN-ACK or other ACK segments (e.g., TCP-AO comes to mind).
>
> At a first cut, the doc needs to address this, e.g., saying that:
> - if any user data is included before the option exchange is completed, it
> has to be delayed until it completes
> - how to handle options that are first seen after the SYN
> MPTCP can define its own behavior for this, but your doc cannot redefine
> that for other options
>
> Key ideas of the draft are the followings.
>> 1: drastic changes in TCP's spec will not be required
>>     (it does not require updating TCP header format nor using multiple
>> SYN packets or additional SYN-like packets)
>>
>>
>> Post-SYN activation of new options is quite a drastic change.
>>
>> Nevermind the question of what happens to data in the SYN, which normally
>> MUST be passed to the application at the receiver after the final ACK is
>> received, but here MUST NOT. And the data that might go in the other
>> direction in the 3rd message with the ACK.
>>
>> Basically, you’re proposing to change the 3WHS to a 5WHS, which is a lot
>> more significant and complex than described here (there are a lot of
>> failure modes not addressed, for one).
>>
>
> RIght. To be precise, the draft supports 3WHS, 4WHS and 5WHS. It can be
> varied depending on how much extra option space is needed.
> MPTCP adopts 4WHS for its negotiation. In my view, the draft just extends
> the idea.
>
>
> MPTCP adopts 4WHS for *its* options, which is its prerogative. You’re
> attempting to define 4WHS and 4WHS semantics for *all* options, which I
> don’t think is viable.
>
> Hence, I am thinking the degree of the complexity would be more or less
> the same. At least, I don't think it will be too complex to implement.
>
> 2: utilize the option negotiation schemes in mptcp for generic purposes.
>> so, I think it can be considered middlebox friendly.
>>
>>
>> MPTCP is negotiating variants of an option that is already active
>> (AFAICT); that’s not the same as activating new options.
>>
>
> My understanding for MPTCP is similar and I think this draft does the same
> things. (from my point of view)
>  If you see significant differences between them, could you elaborate a
> bit?
>
>
> See above.
>
> 3: it has some limitations (e.g it can only extend around 30-40 bytes for
>> SYN option space). But, if it's combined with EDO, we can use more option
>> space.
>>     (depends on how EDO draft will progress, though)
>>
>>
>> If you have EDO, then just negotiate it and activate options after the
>> connection is established. But that’s not the problem at hand - the problem
>> is activation of options in the SYN. AFAICT, this does not do that.
>>
>
> I think the negotiation scheme for EDO is simple. it needs to send 1 bit
> information to indicate the activation of the feature.
> This can be done during SYN exchange. So, I thought it's fine to use this
> feature in the 3rd segment. Or, are there any risks?
>
>
> I do think that if EDO is negotiated in the SYN then you can use it in all
> subsequent segments (that’s already how it’s defined). I don’t think it
> adds any risks here that aren’t already part of EDO.
>
> Joe
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>
>
>