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

[Yoshifumi Nishida <[e-mail]>]

Hi Joe,

On Thu, Feb 11, 2021 at 9:40 AM Joseph Touch <[e-mail]> wrote:

> Hi, Yoshifumi,
>
> On Feb 11, 2021, at 1:05 AM, Yoshifumi Nishida <[e-mail]> wrote:
>
> Hi Joe,
>
> On Wed, Feb 10, 2021 at 7:55 AM Joseph Touch <[e-mail]> wrote:
>
>> Hi, all,
>>
>> FWIW, my view is that:
>>
>> - it MAY be reasonable for an option to negotiate parameters after the
>> TWHS
>> BUT this can be VERY difficult, esp. because the negotiation needs to
>> account for segment loss and reordering
>>
>> - a new option CANNOT provide that opportunity for existing options
>> those existing options were defined assuming establishment during the TWHS
>>
>> - a new option CANNOT provide that opportunity for new options UNLESS
>> THEY EXPLICITLY ALLOW IT
>>
>
> I won't disagree with them, but I have a few comments on them.
>
> - When we try to define new options, I think we cannot ignore option space
> size in today's TCP.
>   If there's risk that the option cannot be fit into SYN, protocol
> designers can think about adopting this approach.
>
>
> I think that applies more to the “compressed” version than the other part,
> but compressed options work only for initially flag (on/off) options with
> no parameters in the SYN.
>
>   Otherwise, they will have to give up using the option or sacrifice some
> of existing options in some situations.
>   I'm not sure if it's very difficult to negotiate parameters after TWHS
> because it has already been done in MPTCP.
>
>
> It has been done *within the option*, not as a general case available to
> option designers. Those are quite different.
>
> - Not all new options need to negotiate parameters. For
> example,draft-gomez-tcpm-ack-rate-request or draft-ietf-tcpm-tcp-edo.
>   For these cases, their options can be put into the aggregated option in
> SYN, which can save some space without any difficulties.
>
>
> Agreed; again, that separates the compressed aspect from other aspects.
> Perhaps creating a single compressed option for the next N such SYN-“flag”
> options would be useful.
>
> - I think we can think about updating existing options to support this
> approach. At least, I think it's not impossible.
>
>
> Updating options is likely to be much more difficult than creating new
> ones, which is itself difficult...
>
>   But, I guess we should focus on using this for new options at first.
>
>
> Agreed - but again, I’d suggest that all the above applies more to a
> single “flag options” option for new options only.
>
> That could be done to support the next 16 such flag options options in one
> word-aligned option. I don’t know that it would be worth trying to optimize
> beyond 16 of those, though.
>
> And I do NOT think that this option should waste space trying to game
> devices that ignorantly reflect SYN options in SYN-ACK. The definition in
> TCP and most such options stands - if an option is reflected in a SYN-ACK,
> it is deemed supported.
>

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.
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.

Thanks,
--
Yoshi



> On Feb 10, 2021, at 2:28 AM, Yoshifumi Nishida <[e-mail]> wrote:
>>
>> Hi Kangjiao,
>>
>> OK. I think it has some similarities. I will think about this further and
>> will get back to you.
>> --
>> Yoshi
>>
>> On Tue, Feb 9, 2021 at 5:14 PM Kangjiao <[e-mail]> wrote:
>>
>>> Hi Yoshi,
>>>
>>>
>>>
>>> I wrote a draft to propose an idea for MPTCP subtype capability exchange
>>> during MPTCP handshake.  We think, in MPTCP, some options are mandatory but
>>> some options can be set as optional ones. So an exchange mechanism of
>>> actual capability between both parties are needed.
>>>
>>>
>>>
>>> URL:
>>> https://www.ietf.org/archive/id/draft-kang-tcpm-subtype-capability-exchange-00.txt
>>>
>>> Status:
>>> https://datatracker.ietf.org/doc/draft-kang-tcpm-subtype-capability-exchange/
>>>
>>> Html:
>>> https://www.ietf.org/archive/id/draft-kang-tcpm-subtype-capability-exchange-00.html
>>>
>>> Htmlized:
>>> https://tools.ietf.org/html/draft-kang-tcpm-subtype-capability-exchange-00
>>>
>>>
>>>
>>> When I read your draft, I think maybe our above work have some relevance
>>> to your suggestions. If you think it'll help with this work, I hope we can
>>> discuss this new negotiation mechanism for related options and subtypes.
>>> Thanks
>>>
>>>
>>>
>>> Best wishes,
>>>
>>> Jiao
>>>
>>>
>>>
>>> *From:* tcpm [mailto:[e-mail]] *On Behalf Of *Yoshifumi
>>> Nishida
>>> *Sent:* Wednesday, February 3, 2021 3:12 PM
>>> *To:* [e-mail] Extensions <[e-mail]>
>>> *Subject:* [tcpm] Fwd: I-D Action: draft-nishida-tcpm-agg-syn-ext-00.txt
>>>
>>>
>>>
>>> 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.
>>>
>>>
>>>
>>> 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)
>>>
>>> 2: utilize the option negotiation schemes in mptcp for generic purposes.
>>> so, I think it can be considered middlebox friendly.
>>>
>>> 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)
>>>
>>>
>>>
>>> Please let me know if you have any questions or comments or suggestions.
>>>
>>>
>>>
>>> Thank you so much!
>>>
>>> --
>>>
>>> Yoshi
>>>
>>>
>>>
>>>
>>>
>>> ---------- Forwarded message ---------
>>> From: <[e-mail]>
>>> Date: Tue, Feb 2, 2021 at 10:45 PM
>>> Subject: I-D Action: draft-nishida-tcpm-agg-syn-ext-00.txt
>>> To: <[e-mail]>
>>>
>>>
>>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>>
>>>
>>>         Title           : Aggregated Option for SYN Option Space
>>> Extension
>>>         Author          : Yoshifumi Nishida
>>>         Filename        : draft-nishida-tcpm-agg-syn-ext-00.txt
>>>         Pages           : 14
>>>         Date            : 2021-02-02
>>>
>>> Abstract:
>>>    TCP option space is scarce resource as its max length is limited to
>>>    40 bytes.  This limitation becomes more significant in SYN segments
>>>    as all options used in a connection should be exchanged during SYN
>>>    negotiations.  This document proposes a new SYN option negotiation
>>>    scheme that provide a feature to compress TCP options in SYN segments
>>>    and provide more option space.  The proposed scheme does not update
>>>    the format of TCP header nor transmit any additional SYN or SYN-like
>>>    segments so that it has lower risks for middlebox interventions.  In
>>>    addition, by combining another proposal for option space extension,
>>>    it is possible to provide further option space.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-nishida-tcpm-agg-syn-ext/
>>>
>>> There are also htmlized versions available at:
>>> https://tools.ietf.org/html/draft-nishida-tcpm-agg-syn-ext-00
>>> https://datatracker.ietf.org/doc/html/draft-nishida-tcpm-agg-syn-ext-00
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of
>>> submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>>
>>> _______________________________________________
>>> I-D-Announce mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/i-d-announce
>>> Internet-Draft directories: http://www.ietf.org/shadow.html
>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>
>> _______________________________________________
>> tcpm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tcpm
>>
>>
>> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm
>
>
>