Re: [tcpm] Francesca Palombini's No Objection on draft-ietf-tcpm-rfc793bis-25: (with COMMENT)

[Benjamin Kaduk <[e-mail]>]

On Wed, Sep 22, 2021 at 02:19:17PM -0700, Francesca Palombini via Datatracker wrote:
> 4. -----
> 
> FP: This is surely me missing something but, in section 3.5 I see:
> 
>    4.  ESTABLISHED --> <SEQ=101><ACK=301><CTL=ACK>       --> ESTABLISHED
> 
>    5.  ESTABLISHED --> <SEQ=101><ACK=301><CTL=ACK><DATA> --> ESTABLISHED
> 
> which is followed by:
> 
>    Note that the sequence number of the segment in line 5 is the same as
>    in line 4 because the ACK does not occupy sequence number space (if
>    it did, we would wind up ACKing ACKs!).
> 
> However, later on, in Figure 13:
> 
>    2.  (Close)                                              (Close)
>        FIN-WAIT-1  --> <SEQ=100><ACK=300><CTL=FIN,ACK>  ... FIN-WAIT-1
>                    <-- <SEQ=300><ACK=100><CTL=FIN,ACK>  <--
>                    ... <SEQ=100><ACK=300><CTL=FIN,ACK>  -->
> 
>    3.  CLOSING     --> <SEQ=101><ACK=301><CTL=ACK>      ... CLOSING
>                    <-- <SEQ=301><ACK=101><CTL=ACK>      <--
>                    ... <SEQ=101><ACK=301><CTL=ACK>      -->
> 
> I am confused why in this case, in line 3, ACK does in fact occupy sequence
> number space. What am I missing?

It is the FIN that occupies sequence number space, not the ACK.

Both steps 2 and 3 show messages being sent "in parallel", i.e., the "..."
in the respective column shows that the event is not currently occuring at
that endpoint.

So in (2), left sends SEQ=100,FIN, and right sends SEQ=300,FIN; since those
sequence numbers are thus committed, in (3) left has to send SEQ=101 and
right has to send SEQ=301.

-Ben