Re: [tcpm] Linux doesn’t implement RFC3465

> On 12. Aug 2021, at 20:44, Vidhi Goel <vidhi_goel=40apple.com@dmarc.ietf.org> wrote:
> 
>> On Thu, Aug 12, 2021 at 11:34 AM Vidhi Goel <vidhi_goel@apple.com> wrote:
>>> 2. If there is no such energy, or there are contentious issues that will draw out the process to get this to RFC, than I can initiate a review of upgrading 3465 to PS directly. I think we all agree this would be an improvement on the status quo, but isn't worth doing if 3465bis is going to happen quickly.
>> 
>> I don’t think 3465 can be upgraded to PS as-is.
>> 
>> Why not?
> 
> Because L=2 as MUST is too constrained for high BDPs and most stacks don’t even follow that.
My reading is:

* However, ABC with L=1*SMSS bytes is more conservative in a
  number of key ways (as discussed in the next section) and therefore,
  this document suggests that even though with L=1*SMSS bytes TCP
  stacks will see little performance change, ABC SHOULD be used.

* This document specifies that TCP implementations MAY use L=2*SMSS
  bytes and MUST NOT use L > 2*SMSS bytes.

* The exception to the above suggestion is during a slow start phase
  that follows a retransmission timeout (RTO).  In this situation, a
  TCP MUST use L=1*SMSS

So I don't think saying L = 2 is a MUST is a summary. For me it is more
important that it says MUST NOT be larger than 2.

Best regards
Michael
> 
> 
>> On Aug 12, 2021, at 11:39 AM, Martin Duke <martin.h.duke@gmail.com> wrote:
>> 
>> 
>> 
>> On Thu, Aug 12, 2021 at 11:34 AM Vidhi Goel <vidhi_goel@apple.com> wrote:
>>> 2. If there is no such energy, or there are contentious issues that will draw out the process to get this to RFC, than I can initiate a review of upgrading 3465 to PS directly. I think we all agree this would be an improvement on the status quo, but isn't worth doing if 3465bis is going to happen quickly.
>> 
>> I don’t think 3465 can be upgraded to PS as-is.
>> 
>> Why not?
>>  
>> Personally, I like the structure of 6928 more than 3465. Is it possible to rope in ABC (3465) in a 6928bis and 
>> change the title - Would like to hear more from the authors of both the RFCs.
>> 
>> It will take a bit more editorial work, but there's no reason a single document can't obsolete both RFCs.
>>  
>> 
>> Thanks,
>> Vidhi
>> 
>> Thanks for writing a draft. That will move things along.
>>  
>> 
> 
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm