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

[Martin Duke <[e-mail]>]

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
>