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

[Martin Duke <[e-mail]>]

Makes sense.

It might be worthwhile to think through some use cases that would motivate
this work, where (1) the total length of desired options is > 40, but (2)
it would be acceptable but suboptimal to have < 40B of options.

A client could then send its required options in the expanded form, and
compress the nice-to-haves in your option.

On Fri, Mar 24, 2023 at 11:39 AM Yoshifumi Nishida <[e-mail]>
wrote:

> Hi Martin,
>
> Thanks for the feedback. Yes, I have thought about the issue before.
> One naive idea is to deploy the aggregated option with a newly defined
> option (probably experimental options).
> Then, we ask implementers to support the aggregated option when they
> implement the new feature.
>
> Also, when we send both the original option and the aggregated option in
> SYN and only aggregated option comes back in SYN/ACK, we can cache the info
> for future connection attempts.
> The basic idea is described in
>
> https://datatracker.ietf.org/doc/html/draft-nishida-tcpm-agg-syn-ext-00#section-5.1
>
> --
> Yoshi
>
> On Fri, Mar 24, 2023 at 11:18 AM Martin Duke <[e-mail]>
> wrote:
>
>> Hi Yoshi,
>>
>> Thanks for this draft. Many years ago, I came quite close to submitting a
>> draft with similar ideas, but it was probably an inferior design to this
>> one.
>>
>> The main reason I didn't was that I didn't see a deployment path -- as
>> long as clients aren't sure if servers support the option, they have to
>> send this aggregated option and the original options, and thus make the
>> space shortage worse rather than better.
>>
>> If the space shortage is in the SYN/ACK only, that's a different matter.
>>
>> Certainly, if we could get most servers to support this, and the
>> consequences of options not getting through are not high, there could be a
>> path.
>>
>> What are your thoughts on how to address this problem?
>>
>> On Thu, Nov 10, 2022 at 2:47 AM Yoshifumi Nishida <[e-mail]>
>> wrote:
>>
>>> Hi Carles,
>>>
>>> Thanks for the feedback. Yes, I agree with 2 bit GID. It's the current
>>> setting in the draft.
>>> I will add some more discussions on this point in the next version.
>>> --
>>> Yoshi
>>>
>>> On Wed, Nov 9, 2022 at 12:07 AM Carles Gomez Montenegro <
>>> [e-mail]> wrote:
>>>
>>>> Hi Yoshi,
>>>>
>>>> Thanks for your response.
>>>>
>>>> There are currently 22 option Kind numbers assigned by IANA (that are
>>>> not obsoleted or temporary). There are also 14 ExID values assigned.
>>>>
>>>> A conservative approach would need to consider all possible
>>>> combinations. It seems that this approach would require a 3-bit GID.
>>>>
>>>> However, probably only a (small?) subset of the possible TCP options
>>>> would be used simultaneously, and therefore a 2-bit GID would appear
>>>> to suffice.
>>>>
>>>> Would this make sense?
>>>>
>>>> Cheers,
>>>>
>>>> Carles
>>>>
>>>>
>>>>
>>>>
>>>> > Hi Carles,
>>>> > Thanks for the feedback.
>>>> > Yes, that's the point I have been wondering about.
>>>> > I agree with your assessments. Do you have any thoughts on the best
>>>> choice among them?
>>>> > --
>>>> > Yoshi
>>>> >
>>>> >
>>>> > On Mon, Nov 7, 2022 at 2:06 AM Carles Gomez Montenegro <
>>>> [e-mail]> wrote:
>>>> >>
>>>> >> Hi Yoshi,
>>>> >>
>>>> >> Thanks for your draft, and for taking into account the needs of a new
>>>> >> experimental proposal such as the TARR option.
>>>> >>
>>>> >> Indeed, currently, 4 bytes is the minimum format size to announce
>>>> >> support of an RFC 6994-conforming experimental TCP option. However,
>>>> as
>>>> >> you mention in your draft, the same information might be conveyed by
>>>> >> using less bits.
>>>> >>
>>>> >> I've been thinking about whether the number of GID bits (i.e., 2
>>>> bits)
>>>> >> is the best choice or not. My own conclusion is that it is, since:
>>>> >>
>>>> >> - Number of GID bits = 0 --> it does not allow to omit unused
>>>> aggregated blocks.
>>>> >> - Number of GID bits = 1 --> it would support only 14 options.
>>>> >> - Number of GID bits = 3 --> it would support 40 options, which
>>>> >> perhaps is not really necessary, and would add one bit of overhead
>>>> per
>>>> >> aggregated block.
>>>> >>
>>>> >> Thanks,
>>>> >>
>>>> >> Carles
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >> > Hi folks,
>>>> >> >
>>>> >> > I have submitted an updated version for aggregated option draft.
>>>> >> > The main points of this version are the following, mainly to
>>>> address Joe's comments.
>>>> >> > - The draft contains now aggregated option only.  delay
>>>> negotiation proposal has been removed and out of scope of the draft.
>>>> >> > - The main target for aggregated option is a new experimental
>>>> proposal such as TARR option while It is possible to aggregate existing
>>>> options with some conditions,
>>>> >> > It would be great if you could provide some feedback.
>>>> >> >
>>>> >> > Thanks,
>>>> >> > --
>>>> >> > Yoshi
>>>> >> >
>>>> >> >
>>>> >> > On Sun, Oct 23, 2022 at 12:15 AM <[e-mail]> wrote:
>>>> >> >>
>>>> >> >>
>>>> >> >> 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-01.txt
>>>> >> >>   Pages           : 9
>>>> >> >>   Date            : 2022-10-23
>>>> >> >>
>>>> >> >> 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 can aggregate multiple TCP options in SYN segments
>>>> into a
>>>> >> >>    single option so that more options can be negotiate during 3
>>>> way
>>>> >> >>    handshake.  With its simple design, the approach does not
>>>> require
>>>> >> >>    fundamental changes in TCP.
>>>> >> >>
>>>> >> >>
>>>> >> >> The IETF datatracker status page for this draft is:
>>>> >> >> https://datatracker.ietf.org/doc/draft-nishida-tcpm-agg-syn-ext/
>>>> >> >>
>>>> >> >> There is also an HTML version available at:
>>>> >> >>
>>>> https://www.ietf.org/archive/id/draft-nishida-tcpm-agg-syn-ext-01.html
>>>> >> >>
>>>> >> >> A diff from the previous version is available at:
>>>> >> >>
>>>> https://www.ietf.org/rfcdiff?url2=draft-nishida-tcpm-agg-syn-ext-01
>>>> >> >>
>>>> >> >>
>>>> >> >> Internet-Drafts are also available by rsync at rsync.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
>>>
>>