From nobody Thu Feb 4 12:35:12 2021 Return-Path: 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 C56513A17D8 for ; Thu, 4 Feb 2021 12:35:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.318 X-Spam-Level: X-Spam-Status: No, score=-1.318 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_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 keqF5Lgp1lhr for ; Thu, 4 Feb 2021 12:35:04 -0800 (PST) Received: from server217-2.web-hosting.com (server217-2.web-hosting.com [198.54.115.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 154DB3A17D3 for ; Thu, 4 Feb 2021 12:35:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; 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=in87zrXRBEU6Xjf+yNE3lRvy1Q6r1SbeoozgYhIBHyI=; b=dyzzUQQTLBDkNNIsbUosuejdI Ei4Z7myns4fHZL9sXCWipykAas9KrjjTbHZJ3zi0mjxwl3ex/ZQ2GnEWyDkVqONhlyytdWUuR/od/ u5z/vmYyKCieyzTAC9VZxfyRXEqzKbYj4tyEpORVwegRgme0V+GeHOG4fftUqpEYizy9rKqgdI8mp jfAq79dh1D603m4PIuWd6kzKiosGwgPHPFZn0xkb9GBnT/oz5c1t8pIYjbNha+62bOHse2cAsiLtI LjJxg92hj38FHgN9Ki3a2nKDTNZz1Xd3KLYgalLIK/OzcVXwoYtfEB6oAQh0M7S3Islw5vyqLe/0L hrqtBmWxQ==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:60632 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.93) (envelope-from ) id 1l7lL8-002JZ9-Ls; Thu, 04 Feb 2021 15:35:03 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_7729FEDA-2128-4B91-BDB6-96B1EEE5FA45" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) From: Joseph Touch In-Reply-To: <8C6762C8-2A22-4CC7-AF53-1D13FC3DC268@strayalpha.com> Date: Thu, 4 Feb 2021 12:34:58 -0800 Cc: "tcpm@ietf.org Extensions" Message-Id: References: <161233469809.31214.294457730576935197@ietfa.amsl.com> <244FE3E7-7B83-4884-B11B-028F7167B549@strayalpha.com> <8C6762C8-2A22-4CC7-AF53-1D13FC3DC268@strayalpha.com> To: Yoshifumi Nishida X-Mailer: Apple Mail (2.3654.40.0.2.32) 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 - 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2021 20:35:07 -0000 --Apple-Mail=_7729FEDA-2128-4B91-BDB6-96B1EEE5FA45 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 FWIW, I would have called this more =E2=80=9Cdelayed option = negotiation=E2=80=9D than its current title. 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. Joe > On Feb 4, 2021, at 12:07 PM, Joseph Touch = wrote: >=20 > Hi, Yoshifumi, >=20 >> On Feb 3, 2021, at 11:02 PM, Yoshifumi Nishida > wrote: >>=20 >> Hi Joe, >>=20 >> Thanks for reading the draft. I put my comments in lines. >>=20 >> On Wed, Feb 3, 2021 at 4:46 PM Joseph Touch > wrote: >> Hi, Yoshi, >>=20 >>> On Feb 2, 2021, at 11:12 PM, Yoshifumi Nishida > wrote: >>>=20 >>> Hi folks, >>>=20 >>> 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.=20 >>> But, I'm thinking that it might be a good time to discuss it again. >>=20 >> The proposal has two parts, which are (AFAICT) separable: >> A. Aggregated options >> B. Adding more option space in the 3rd packet of a 3WHS >>=20 >> Right. both can be used supplementarily. >> =20 >> (A) is fine, although the most significant issue is legacy = interaction. >>=20 >> (B) is no longer extending the SYN; it=E2=80=99s actually just = post-SYN activation of new options.=20 >>=20 >> In my view, all options are negotiated during SYN exchange. There's = no post SYN activation.=20 >> They are just additional information for the features already = negotiated during SYN exchanges. >=20 > I disagree; you=E2=80=99re suggesting putting NEW options in packets = that don=E2=80=99t have a SYN. In that sense, it=E2=80=99s similar to my = proposal, which uses a segment with no SYN and no ACK bit (the = out-of-band segment). >=20 > 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=E2=80=99= 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). >=20 > 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=20 >=20 >>> Key ideas of the draft are the followings. >>> 1: drastic changes in TCP's spec will not be required=20 >>> (it does not require updating TCP header format nor using = multiple SYN packets or additional SYN-like packets) >>=20 >> Post-SYN activation of new options is quite a drastic change.=20 >>=20 >> 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. >>=20 >> Basically, you=E2=80=99re 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). >>=20 >> 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.=20 >=20 > MPTCP adopts 4WHS for *its* options, which is its prerogative. = You=E2=80=99re attempting to define 4WHS and 4WHS semantics for *all* = options, which I don=E2=80=99t think is viable. >=20 >> 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. >>=20 >>> 2: utilize the option negotiation schemes in mptcp for generic = purposes. so, I think it can be considered middlebox friendly. >>=20 >> MPTCP is negotiating variants of an option that is already active = (AFAICT); that=E2=80=99s not the same as activating new options. >>=20 >> 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? >=20 > See above. >=20 >>> 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) >>=20 >> If you have EDO, then just negotiate it and activate options after = the connection is established. But that=E2=80=99s not the problem at = hand - the problem is activation of options in the SYN. AFAICT, this = does not do that. >>=20 >> I think the negotiation scheme for EDO is simple. it needs to send 1 = bit information to indicate the activation of the feature.=20 >> 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? >=20 > I do think that if EDO is negotiated in the SYN then you can use it in = all subsequent segments (that=E2=80=99s already how it=E2=80=99s = defined). I don=E2=80=99t think it adds any risks here that aren=E2=80=99t= already part of EDO. >=20 > Joe >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_7729FEDA-2128-4B91-BDB6-96B1EEE5FA45 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 FWIW,= I would have called this more =E2=80=9Cdelayed option negotiation=E2=80=9D= than its current title.

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.

Joe

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=E2=80=99s 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=E2=80=99re suggesting = putting NEW options in packets that don=E2=80=99t have a SYN. In that = sense, it=E2=80=99s 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=E2=80=99t 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=E2=80=99re 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=E2=80=99re attempting to define 4WHS and = 4WHS semantics for *all* options, which I don=E2=80=99t 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=E2=80=99s = 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=E2=80=99= 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=E2=80=99s already how it=E2=80=99s defined). I don=E2=80=99t think = it adds any risks here that aren=E2=80=99t already part of = EDO.

Joe

_____________________________________________= __
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

= --Apple-Mail=_7729FEDA-2128-4B91-BDB6-96B1EEE5FA45--