Re: [tcpm] TCP EDO and SYN-EXT-OPT finalization - request for discussion

["[e-mail]" <[e-mail]>]

Hi, Yoshi, 

> On Oct 31, 2022, at 1:38 AM, Yoshifumi Nishida <[e-mail]> wrote:
> 
> Hi Joe, 
> 
> Thanks for the clarification. 
> As far as I read the draft, I guess the summaries for EDO with TSO are something like this. Is this correct?
> 
> 1: EDO can live with TSO adopters if they don't coalesce nor split the segments with unknown options. If not, they need to be updated.

Yes, that’s specifically for legacy TSO adapters.

> 2: This means when EDO is used in a connection, TSO will be disabled for the connection as EDO option must be placed in all segments

No; only incorrectly implemented legacy TSO adapter would need to be disabled for that connection. 

A legacy TSO adapter that handled unknown options correctly would basically disable itself, so no application-level action would be needed.

An EDO-aware TSO would not need to be disabled and would not need to disable itself.

> 3: EDO can identify wrong TSO behavior if it uses EDO option with segment length, but cannot with EDO option with simple variant

Yes.

> 4: If TSO-enabled adopters support EDO, TSO can be used with EDO without disabling the feature.

Or if legacy TSO implementations either already did the correct thing or were updated to do the correct thing for unknown options.

> 5: in order to achieve 4:, one approach could be to standardize EDO.   

Standardizing EDO is already in TCPM charter.

Standardizing EDO affects only whether/when TSO implementations could support EDO; either way, incorrectly implemented TSOs can be fixed right now.

The better way to think of this is that standardizing EDO can help users detect incorrectly implemented TSO, which means that bug (of not ignoring unknown TCP options) can get fixed, which benefits not only EDO but all new TCP options.

Joe

> --
> Yoshi
> 
> On Sat, Oct 29, 2022 at 10:45 AM [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>> wrote:
>> Sure - the issue was clarifying the way in which EDO interacts with TCP segment offload (TSO). The diffs are at the end of section 9, as shown here:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-tcp-edo-13.txt
>> 
>> The goal is to be more clear that this is a bug in TSO that EDO adopters need to be on the lookout for.
>> 
>> Joe
>> 
>> —
>> Dr. Joe Touch, temporal epistemologist
>> www.strayalpha.com <http://www.strayalpha.com/>
>> 
>>> On Oct 24, 2022, at 10:13 AM, Yoshifumi Nishida <[e-mail] <mailto:[e-mail]>> wrote:
>>> 
>>> Hi Joe,
>>> 
>>> Thanks for the update. Could you elaborate the changes a bit more? I am sorry that I missed what the feedback was. 
>>> --
>>> Yoshi
>>> 
>>> On Sat, Oct 22, 2022 at 4:25 PM [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>> wrote:
>>>> FYI - both docs have been updated.
>>>> 
>>>> The EDO doc includes some long-pending changes based on feedback from Michael Scharf, regarding TSO. It should be ready for WGLC.
>>>> 
>>>> Joe
>>>> 
>>>> —
>>>> Dr. Joe Touch, temporal epistemologist
>>>> www.strayalpha.com <http://www.strayalpha.com/>
>>>> 
>>>>> On Mar 4, 2022, at 11:05 AM, [e-mail] <mailto:[e-mail]> wrote:
>>>>> 
>>>>> Hi, all,
>>>>> 
>>>>> I’d like to request:
>>>>> 
>>>>> a) WGLC for EDO
>>>>> 
>>>>> b) some sort of WG decision on whether to adopt it as experimental (and, AFAICT, go to WGLC, given we’re already been around the block with it) or give me the go-ahead to submit it as individual experimental
>>>>> 
>>>>> Both drafts are active through April, so I’ll hold on re-issuing until (b).
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> 
>>>>> —
>>>>> Dr. Joe Touch, temporal epistemologist
>>>>> www.strayalpha.com <http://www.strayalpha.com/>
>>>>> 
>>>>>> On Oct 12, 2021, at 1:07 PM, Wesley Eddy <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>> 
>>>>>> On 10/12/2021 3:50 PM, [e-mail] <mailto:[e-mail]> wrote:
>>>>>>> 
>>>>>>> - are there any open issues or pending suggestions to TCP EDO to prepare it for last call?
>>>>>>> 
>>>>>> I think it's in good shape for a last call.  It's stable and addresses all of the feedback to date, aside from greater implementation and field experience.  At the moment, it seems like QUIC has solved the burning need we had for TCP options space, by attracting all the work that would normally need more options. However, after many years of discussion about how to handle this for TCP, and many candidates, the EDO approach was the one the working group was able to get consensus around, and we really should wrap up and publish it, IMHO.
>>>>>> 
>>>>>> 
>>>>>>> - would the WG like to adopt SYN-EXT-OPT as experimental as well or would it be preferred (and OK) to submit this as individual/experimental if not?
>>>>>>> 
>>>>>> Either approach is fine with me, and I prefer either of them rather than not advancing anything.  I would be willing to contribute reviews for either path.
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> tcpm mailing list
>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>>> 
>>>>> _______________________________________________
>>>>> tcpm mailing list
>>>>> [e-mail] <mailto:[e-mail]>
>>>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>> 
>> 
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm