Re: [tcpm] 793bis ready to go?

["Scheffenegger, Richard" <[e-mail]>]

Well, making the transmission of the ACK-only-the-SYN optional when data
is present, which needs to be ACK'd anyway..

That way, current FBSD and Linux behaviour both would comply with
793bis, while I agree with Michael T. that the behavior of FBSD is more
efficient.

Richard

Am 20.02.2021 um 22:53 schrieb Michael Tuexen:
>
>
>> On 20. Feb 2021, at 22:37, Joseph Touch <[e-mail]> wrote:
>>
>> Even if you prefer the FreeBSD variant, the text below doesn’t appear to fix this; it will end up sending the SYN-ACK of the received data *and a second ACK* at the end of the sixth step.
> I think the idea of Richard is that if the text is
>
>           If SND.UNA > ISS (our SYN has been ACKed), change the
>           connection state to ESTABLISHED, form an ACK segment
>           <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
>           and should send it.
>
> Then NOT following the should, but only send the ACK at the end of step 6.
> Wouldn't that work?
>
> Best regards
> Michael
>>
>> Joe
>>
>>> On Feb 20, 2021, at 12:56 PM, [e-mail] wrote:
>>>
>>>> On 18. Feb 2021, at 14:59, Scheffenegger, Richard <[e-mail]> wrote:
>>>>
>>>> One more nit, around dealing with data-in-SYN,ACK
>>>>
>>>> 793bis (page 71) has this text, which unfortunately doesn have any
>>>> RFC2119 language.
>>>>
>>>> But in short, it seems to require the transmission of a pure ACK just
>>>> for the SYN bit, and a 2nd ACK right afterwards (step 6) to acknowledge
>>>> the data.
>>>>
>>>> The FBSD implementation was found to skip over the ACK-only-the-SYN
>>>> intermediate step (which must be acceptable, as that ACK may get lost in
>>>> the network), sending out only the cummulative ACK for SYN and data,
>>>> after having transitioned into ESTABLISHED.
>>> Hi,
>>>
>>> I really prefer the FreeBSD behaviour. A TCP stack should not need to send
>>> two segments at the same time when handling the event of a single segment reception.
>>>
>>> Best regards
>>> Michael, as an individual
>>>>
>>>> But strictly speaking, this behavior is a deviation from 793 / 793bis.
>>>>
>>>> Perhaps a "and should send it" would do, to allow this behavior,
>>>> conserving one pure ACK...
>>>>
>>>> Best regards,
>>>> Richard
>>>>
>>>>
>>>>
>>>> If the state is SYN-SENT then
>>>>
>>>>        first check the ACK bit
>>>>
>>>>           If the ACK bit is set
>>>> :
>>>> :
>>>> fourth check the SYN bit
>>>>
>>>>           This step should be reached only if the ACK is ok, or there
>>>>           is no ACK, and it the segment did not contain a RST.
>>>>
>>>>           If the SYN bit is on and the security/compartment is
>>>>>>>        acceptable then, RCV.NXT is set to SEG.SEQ+1, IRS is set to
>>>>           SEG.SEQ.  SND.UNA should be advanced to equal SEG.ACK (if
>>>>           there is an ACK), and any segments on the retransmission
>>>>           queue that are thereby acknowledged should be removed.
>>>>
>>>>           If SND.UNA > ISS (our SYN has been ACKed), change the
>>>>           connection state to ESTABLISHED, form an ACK segment
>>>>
>>>>>>>           <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
>>>>
>>>>           and send it.  Data or controls that were queued for
>>>>           transmission may be included.  If there are other controls
>>>> or text in the segment then continue processing at the sixth
>>>>           step below where the URG bit is checked, otherwise return.
>>>>
>>>> _______________________________________________
>>>> tcpm mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>
>>> _______________________________________________
>>> tcpm mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tcpm
>>
>> _______________________________________________
>> tcpm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tcpm
>
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm
>