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

From: Francesca Palombini via Datatracker <[email-masked]>
Date: Wed, 22 Sep 2021 14:19:17 -0700

Francesca Palombini has entered the following ballot position for
draft-ietf-tcpm-rfc793bis-25: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the work on this document. I only have minor comments, and some
questions.

I have divided comments into "minor" (including the questions) and "nits".
Neither require replies strictly speaking, please feel free to address as you
see fit. I will appreciate answers to my questions, to improve my
understanding. If any clarification comes out of it, I hope it will help
improve the document.

Francesca

## minor

1. -----

Figure 1

FP: The figure's capture is "TCP Header Format", but Options and Data are
included as well.

2. -----

Figure 2

FP: For consistency, I would have kept the same style as in Figure 1.
Additionally, the IPv4 fields below do not have their size explicitly
specified, so using the same type of formatting as in Figure 1 would help, IMO.

3. -----

       0
       0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-+
      |       0       |
      +-+-+-+-+-+-+-+-+

FP: More of a question than a comment: how come this change, compared to RFC
793? Any particular reason, or was it only for readability?

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?

## nit

5. -----

   Initial Sequence Number Selection

FP: I assume this (and following) was not numbered to keep it as close as
possible to the original RFC, is that right? For readability, I would suggest
numbering these subsections.

---

From: Jeremy Harris <[email-masked]>
Date: Thu, 23 Sep 2021 09:35:48 +0100

> number space. What am I missing?

FIN occupies sequence space.
-- 
Cheers,
   Jeremy

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 30 Sep 2021 13:12:03 -0700

> 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

---

From: Francesca Palombini <[email-masked]>
Date: Thu, 30 Sep 2021 21:36:37 +0000

Ben,

Thank you for your reply. I did read “occupy sequence number space” as “the peer needs to increase the sequence number before sending”, which is why I was puzzled by the ACK getting sent with SEQ += 1 (might be worth to clarify).

However I am still missing something: when I look at Figure 7 I see something similar to what happens in Figure 14, but this time with SYN:

   2.  SYN-SENT     --> <SEQ=100><CTL=SYN>              ...

   3.  SYN-RECEIVED <-- <SEQ=300><CTL=SYN>              <-- SYN-SENT

   4.               ... <SEQ=100><CTL=SYN>              --> SYN-RECEIVED

   5.  SYN-RECEIVED --> <SEQ=100><ACK=301><CTL=SYN,ACK> ...

I am looking at lines 2 and 5. Peer A sends the SYN with SEQ 100, and then sends the SYN and ACK with the same SEQ 100. Making the parallel with what you say below, shouldn’t then in this case the SYN message occupy sequence number space, and the next message sent (line 5.) getting SEQ=101?

Francesca

From: Benjamin Kaduk <[email-masked]>
Date: Thursday, 30 September 2021 at 22:12
To: Francesca Palombini <[email-masked]>
Cc: The IESG <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: Francesca Palombini's No Objection on draft-ietf-tcpm-rfc793bis-25: (with COMMENT)

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 30 Sep 2021 14:41:50 -0700

Hi Francesca,

My confidence level is not as high on this point, but I believe that the
difference here is that the segment being sent still includes the SYN flag.
So, the combination of SEQ=100 with CTL=SYN means that "sequence number 100
is the SYN flag".  In this example of parallel open, the right-side peer
hasn't ack'd the left side's SYN, so the SYN needs to be resent in the
SYN|ACK, and so the segment's sequence number is set to reflect the
(unchanged) initial sequence number.

-Ben

---

From: Francesca Palombini <[email-masked]>
Date: Thu, 30 Sep 2021 21:46:00 +0000

Thanks Ben, it does make sense that that would be the reason for not stepping up the SEQ. I will suggest to the authors to clarify a bit on the point of “occupying sequence number”, if they can, as it would have helped my understanding.

Francesca

Date: Thursday, 30 September 2021 at 23:42

-Ben