Subject: Re: [tcpm] review of rev 14 of RFC 793 bis part 1 of 2 - Editorial Comments

From: Wesley Eddy <[email-masked]>
Date: Tue, 17 Dec 2019 09:29:19 -0500

Hi Gorry, I've been applying all of the editorial comments from your 
review, and they should show up in an update later this week.

There are some of them that I had quick responses to.

> ---
> OLD:
>   An "XXX" indicates a segment which is lost or rejected.
> - rejected seems odd here.
> NEW:
>   An "XXX" indicates a segment that is lost (not processed by the 
> receiving TCP endpoint).

Strangely, it seems like in 793, the "XXX" is explained, but never 
occurs otherwise in the text or diagrams.  I think we can just remove 
this sentence entirely?

> multiple OLD: "TCPs" and "a TCP"
> - This use of a "TCP" as an entity read as very ugly to me. I had to 
> read the sentences several times to parse them, could we explain that 
> we mean, i.e. "TCP endpoints" or "TCP implementations" etc. (usually 
> this seems to mean implementation). 
I'm fine with doing this.  It's a lot of changes though, so I wanted to 
quickly see if anyone strongly disagrees with doing this.

> OLD:
>    SYN (pun intended)
> - I didn't see the pun, can this be explained or omitted?

I think the intent from Jon (or whoever originally wrote this part) was 
"original sin".  We should probably remove this anyways in order to 
avoid cultural references that may not be understood by everyone.

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 17 Dec 2019 14:55:40 +0000

On 17/12/2019 14:29, Wesley Eddy wrote:
> I'm fine with doing this.  It's a lot of changes though, so I wanted 
> to quickly see if anyone strongly disagrees with doing this.
>
>
>> OLD:
>>    SYN (pun intended)
> I think the intent from Jon (or whoever originally wrote this part) 
> was "original sin".  We should probably remove this anyways in order 
> to avoid cultural references that may not be understood by everyone.
>

Understood. That sounds fine. I'm sure you'll do the correct thing,

Gorry

---

From: "Rodney W. Grimes" <[email-masked]>
Date: Tue, 17 Dec 2019 08:49:00 -0800 (PST)

> There are some of them that I had quick responses to.

Some feedback on inteneded actions.

> 
> > ---
> > OLD:
> > ? An "XXX" indicates a segment which is lost or rejected.
> > ? An "XXX" indicates a segment that is lost (not processed by the 
> > receiving TCP endpoint).
> 
> occurs otherwise in the text or diagrams.? I think we can just remove 
> this sentence entirely?

Searching 761 (obsoleted by 793) I see the same text, definition of XXX,
but no usage.  I suspect a diagram was revised, dropping out the XXX
and the refering text was not updated.

> I'm fine with doing this.? It's a lot of changes though, so I wanted to 

This has always bothered me in documents that use TCP in this manner,
though I believe it goes beyond RFC793, correcting it here may be a
good idea, though making sure that all the corrections are right
shall take a keen editorial eye.

> > ?? SYN (pun intended)
> "original sin".? We should probably remove this anyways in order to 

Agreed, Pun's are fine on email lists and in personal communications,
they however do not have a place in standards documents.

--
Rod Grimes                                                 [email-masked]

---

From: Wesley Eddy <[email-masked]>
Date: Tue, 17 Dec 2019 12:12:23 -0500

I've been working on this comment a bit, and wanted to consult the 
wisdom of the working group:

On 8/28/2019 11:20 AM, Gorry Fairhurst wrote:
> I was amused at the frequent reference to "crash" or "crashing". I'm 
> not sure that presents the correct view of the IETf about the 
> stability of the TCP stack and certainly is not what IO would expect 
> in an RFC that could be promoted to full standard. I think this needs 
> to be changed. 

I was looking at the way "crash" is used on a case-by-case basis, and I 
think we could mostly change this to "endpoint failures" or a host 
"rebooting" rather than "crashing"?  Is there any other terminology or 
condition that should be explicitly mentioned somehow?  The important 
point in most places where "crash" is used is that the host has lost all 
of its memory about connections in-progress and associated connection 
state, and that's easy to retain without saying "crash".

---

From: Jonathan Morton <[email-masked]>
Date: Tue, 17 Dec 2019 20:25:50 +0200

> On 17 Dec, 2019, at 7:12 pm, Wesley Eddy <[email-masked]> wrote:
> 
> I was looking at the way "crash" is used on a case-by-case basis, and I think we could mostly change this to "endpoint failures" or a host "rebooting" rather than "crashing"?  Is there any other terminology or condition that should be explicitly mentioned somehow?  The important point in most places where "crash" is used is that the host has lost all of its memory about connections in-progress and associated connection state, and that's easy to retain without saying "crash".

I think using "reboot" would be a good substitute here.

 - Jonathan Morton

---

From: "Rodney W. Grimes" <[email-masked]>
Date: Tue, 17 Dec 2019 10:31:38 -0800 (PST)

> I think using "reboot" would be a good substitute here.

Or define CRASH as terminology:

CRASH:	Lost of state by an endpoint, which may be the result of a reboot, power failure, software failure or any other mechanisim.

Then you can leave all the other text as is, and just s/crash/CRASH/g

---

From: Wesley Eddy <[email-masked]>
Date: Wed, 18 Dec 2019 16:33:46 -0500

I don't think I noticed anyone responding to Gorry's comment below, and 
I haven't made any alterations in the 793bis draft with regard to this 
(other than fixing some spelling mistakes).  I wanted to pull this into 
its own thread in case other people have thoughts or would like to 
discuss further what the quiet time concept's relevance is in 2020.

On 8/28/2019 11:39 AM, Gorry Fairhurst wrote:
> OLD, Section: "   The TCP Quiet Time Concept"
> - Found this section quite amusing. Is this concept widely implemented 
> in stacks?
> - The examples given need updated, for instance one example starts "At 
> 2 megabits/sec. it takes 4.5 hours to", clearly at 10 Gbps this line 
> of thinking becomes problematic.
> - There is an odd sentence that states:
> "In the absence of knowledge
>    about the sequence numbers used on a particular connection, the TCP
>    specification recommends that the source delay for MSL seconds before
>    emitting segments on the connection, to allow time for segments from
>    the earlier connection incarnation to drain from the system."
> - how would the "source" know the MSL rather than use the Internet 
> default?
> - To me, this section raises many questions about whether this is best 
> current practice.

---

From: Yuchung Cheng <[email-masked]>
Date: Wed, 18 Dec 2019 17:27:33 -0800

> discuss further what the quiet time concept's relevance is in 2020.
I probably am missing something. What's the issue of the text? Linux
to my knowledge does
not implement this quiet time.
But there are other injection attacks or basic checksum issues etc to
corrupt TCP. (Serious) application that solely relying on TCP's
integrity is signing up for troubles already ...

> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Neal Cardwell <[email-masked]>
Date: Wed, 18 Dec 2019 23:16:14 -0500

> integrity is signing up for troubles already ...

I would agree with Yuchung's remarks and the general point that the
"TCP Quiet Time Concept" from RFC 793 does not seem to be of practical
importance today, from a number of perspectives:

o I'm not aware of any major TCP implementation that actually follows
the "TCP Quiet Time" approach.

o Most production applications AFAIK end up using SO_REUSEADDR,
indicating a need to reuse ports quickly and a lack of concern about
this kind of issue with old packets ending up mixed into new
connections.

o Applications that care about this should be using cryptography.

o Users today expect to be able to reboot a machine and get back on
the network in less than 2 minutes.

best,
neal

---

From: Matt Mathis <[email-masked]>
Date: Wed, 18 Dec 2019 21:39:23 -0800

I am under the impression that web servers do something different:
Normally the client sends the FIN, and the server holds FIN wait, but often
discards it before 2MSL to reduce memory pressure, however if the server
receives a new SYN for the same connection 4tuple (before it is discarded),
the server has the option to continue in the same sequence space, one byte
after the FIN.

I haven't looked, but what happens if a connection is in FIN wait, and a
new SYN arrives?

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

We must not tolerate intolerance;
       however our response must be carefully measured:
            too strong would be hypocritical and risks spiraling out of
control;
            too weak risks being mistaken for tacit approval.

---

From: Joe Touch <[email-masked]>
Date: Thu, 19 Dec 2019 06:57:17 -0800

This discussion seems to be overlooking the effect of timestamps.

Joe

> On Dec 18, 2019, at 9:39 PM, Matt Mathis <mattmathis=[email-masked]> wrote:
> 
> I am under the impression that web servers do something different:  Normally the client sends the FIN, and the server holds FIN wait, but often discards it before 2MSL to reduce memory pressure, however if the server receives a new SYN for the same connection 4tuple (before it is discarded), the server has the option to continue in the same sequence space, one byte after the FIN.
> 
> I haven't looked, but what happens if a connection is in FIN wait, and a new SYN arrives?
> 
> Thanks,
> --MM--
>             too strong would be hypocritical and risks spiraling out of control;
> On Wed, Dec 18, 2019 at 8:16 PM Neal Cardwell <ncardwell=[email-masked] <mailto:[email-masked]>> wrote:
> <ycheng=[email-masked] <mailto:[email-masked]>> wrote:
> >
> > On Wed, Dec 18, 2019 at 1:33 PM Wesley Eddy <[email-masked] <mailto:[email-masked]>> wrote:
> > >
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/tcpm <https://www.ietf.org/mailman/listinfo/tcpm>

---

From: Wesley Eddy <[email-masked]>
Date: Thu, 19 Dec 2019 11:22:33 -0500

Gorry had a few comments on the "Reset Generation" section of 793bis 
that I have some proposed responses for:

On 8/28/2019 11:39 AM, Gorry Fairhurst wrote:
> ---
> OLD:
>     As a general rule, reset (RST) must be sent whenever...
> - I can't fathom what was intended, isn't this a RFC2119 SHOULD?

I think there's more specific text elsewhere, so we probably shouldn't 
put 2119 language here.  Instead of "must be sent" we might just say "is 
sent".

> ---
> OLD:
>    SYNs addressed to a non-existent connection are
>    rejected by this means.
> - Is that a complicated way of saying an RST is sent, or is it 
> something else, please clarify,
> is the word "addressed" correct here? Could this be rewritten as a 
> "SYN segment that
> does not match an existing connection..."

I'm fine with this editorial change, if nobody objects.

> - This then leads me to ask why this does not refer to SYN cookies?

I'm not sure that's needed or directly relevant, because SYN cookies are 
for protecting actual listening sockets (not non-existent ones).

> ---
> OLD:
>       any unacceptable segment (out of window sequence number or
>       unacceptable acknowledgment number) must elicit only an empty
>       acknowledgment segment containing
> - what does "elicit" mean here and what is an empty ACK segment?

I think it's just editorial, but we could change:

"elicit only an empty acknowledgement segment"

to:

"be responded to with an empty acknowledgement segment (without any user 
data)"

---

From: Wesley Eddy <[email-masked]>
Date: Thu, 19 Dec 2019 11:26:01 -0500

I'm planning to apply Gorry's suggested text below directly, unless 
anyone has objections or other thoughts?

On 8/28/2019 11:39 AM, Gorry Fairhurst wrote:
> OLD:
> 3.7.5.  IPv6 Jumbograms
>
>    In order to support TCP over IPv6 jumbograms, implementations need to
>    be able to send TCP segments larger than the 64KB limit that the MSS
>    option can convey.  RFC 2675 [6] defines that an MSS value of 65,535
>    bytes is to be treated as infinity, and Path MTU Discovery [3] is
>    used to determine the actual MSS.
> - This was discussed in the 6Man WG in Montreal, and while there was no
> consensus reached to obsolete jumbograms, there was encouragement
> to ensure that specs describe jumbo grams appropriate, rather than
> suggesting support is required. In this sense, I recommend adding
> something like:
> NEW:
>    The Jumbo Payload option need not be implemented or understood by
>    IPv6 nodes that do not support attachment to links with a MTU greater
>    than 65,575 [RFC2675], and  the present IPv6 Node Requirements
>    does not include support for Jumbograms [RFC8504].

---

From: Wesley Eddy <[email-masked]>
Date: Thu, 19 Dec 2019 11:53:38 -0500

I'm not sure the comment & suggested NEW text below is quite correct.  I 
tracked the text in question down to being from RFC 6691 (and it first 
appeared in -03 of draft-ietf-tcpm-tcpmss-03, and it looks like it came 
about from a thread here: 
https://mailarchive.ietf.org/arch/msg/tcpm/LjfmysjQAKmTudpBgBa2Jp20O3M ).

On 8/28/2019 11:39 AM, Gorry Fairhurst wrote:
> OLD:
>    As a result, when the effective MTU of an interface varies, TCP
>    SHOULD use the smallest effective MTU of the interface to calculate
>    the value to advertise in the MSS option (SHLD-6).
> - what does "varies" mean here? The MSS is computed when the SYN is 
> exchanged
> is this actually just:
> NEW:
>    When multiple IP interfaces have different effective MTUs, TCP
>    SHOULD use the smallest effective MTU of the interface to calculate
>    the value to advertise in the MSS option (SHLD-6).

---

From: Wesley Eddy <[email-masked]>
Date: Thu, 19 Dec 2019 12:04:31 -0500

While I think Gorry's comment below is pretty much correct, this is 
direct from RFC 1122's material on TCP.  I'm proposing not to change 
anything about this at the moment, since I don't think any harm is done 
by saying this.

On 8/28/2019 11:39 AM, Gorry Fairhurst wrote:
> Section 3.8.1
> OLD:
>    If a retransmitted packet is identical to the original packet (which
>    implies not only that the data boundaries have not changed, but also
>    that the window and acknowledgment fields of the header have not
>    changed), then the same IP Identification field MAY be used (see
>    Section 3.2.1.5 of RFC 1122) (MAY-4).
> - What is this MAY about? Is it about the IPv4 IPID field and is that 
> really
> important for a TCP spec?

---

From: David Borman <[email-masked]>
Date: Thu, 19 Dec 2019 11:21:24 -0600

This has to do with the fact that the IPID field is used to do fragmentation reassembly.  It is ok to reuse the same IPID when retransmitting, as long as the retransmitted packet is identical to the original packet, not just the TCP data, but also all the TCP headers.  If the two packets aren’t identical and they are fragmented, then using the same IPID could cause the receiver to not properly reassemble the packet.

What this also says is that, if a TCP implementation is such that it buffers up previously sent packets for possible retransmission and retransmits them verbatim, it doesn’t have to change the IPID just because it is a retransmission.  But if there are any differences between the original and the retransmitted packet, then the IPID must be updated.

			-David Borman

> On Dec 19, 2019, at 11:04 AM, Wesley Eddy <[email-masked]> wrote:
> 
> While I think Gorry's comment below is pretty much correct, this is direct from RFC 1122's material on TCP.  I'm proposing not to change anything about this at the moment, since I don't think any harm is done by saying this.
> 
>> - What is this MAY about? Is it about the IPv4 IPID field and is that really

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 19 Dec 2019 17:24:02 +0000

On 19/12/2019, 16:53, Wesley Eddy wrote:
> I'm not sure the comment & suggested NEW text below is quite correct.  
> I tracked the text in question down to being from RFC 6691 (and it 
> first appeared in -03 of draft-ietf-tcpm-tcpmss-03, and it looks like 
> it came about from a thread here: 
You are indeed correct!

This makes muchmore sense if we refer back to that thread, which was 
about the same interface having maximum packet sizes that vary from 
packet-to-packet, e.g. from  variable-length headers/encapsulations are 
used by the local a link.

An interface SHOULD use the smallest effective MTU that can be used in 
all packets to calculate the value to advertise in the MSS option (SHLD-6).

Gorry

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 19 Dec 2019 17:32:50 +0000

I get this - but if we keep this, I think it should expliclity say *all 
headers have not changed*.

I still think this is a terrible hack to say the transport touches 
something in the network layer - because I have no idea how this sits 
with using TSOpt to disam=biguate retransmissions and extension headers, 
should they be used.

Anyway, this is so very IPv4 centric, I think if we keep this, we should 
call IPv4 out explicitly.

Gorry

On 19/12/2019, 17:21, David Borman wrote:
>> On Dec 19, 2019, at 11:04 AM, Wesley Eddy<[email-masked]>  wrote:
>>

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 19 Dec 2019 18:47:08 +0100

> On 19. Dec 2019, at 18:32, Gorry Fairhurst <[email-masked]> wrote:
> 
> I get this - but if we keep this, I think it should expliclity say *all headers have not changed*.
The TCP timestamp option comes up to my mind. For TCP retransmission, the TSVal would be different.

Best regards
Michael
> 
> I still think this is a terrible hack to say the transport touches something in the network layer - because I have no idea how this sits with using TSOpt to disam=biguate retransmissions and extension headers, should they be used.
> 
> Anyway, this is so very IPv4 centric, I think if we keep this, we should call IPv4 out explicitly.
> 
> Gorry
>

---

From: Matt Mathis <[email-masked]>
Date: Thu, 19 Dec 2019 10:42:33 -0800

What Joe said s/effect/opportunities/

Is there standards language anywhere about successive connections sharing
sequence space and timestamps?  If there is, I missed it.

Thanks,
--MM--

On Thu, Dec 19, 2019 at 6:57 AM Joe Touch <[email-masked]> wrote:

> On Dec 18, 2019, at 9:39 PM, Matt Mathis <
> mattmathis=[email-masked]> wrote:
>

---

From: Wesley Eddy <[email-masked]>
Date: Thu, 19 Dec 2019 17:01:30 -0500

Gorry asked a question below about excessive TCP retransmissions 
resulting in triggering of whatever kind of lower-layer "dead gateway" 
detection logic might be available.  This comes from RFC 1122.  I don't 
know the current state of practice, or of any RFCs amending this, so am 
very interested in any feedback from the list on whether some change 
here is needed.

On 8/28/2019 11:39 AM, Gorry Fairhurst wrote:
> Section 3.8.3
> OLD:
>       pass negative advice (see [14]
>       Section 3.3.1.4) to the IP layer, to trigger dead-gateway
>       diagnosis.
> - Is this still best current practice? - If so please explain and cite 
> RFCs.

---

From: Wesley Eddy <[email-masked]>
Date: Thu, 19 Dec 2019 17:06:43 -0500

Regarding Gorry's comment below, I have an alternative suggestion.  I 
think the details are discussed well in 5681 
https://tools.ietf.org/html/rfc5681#section-4.2 and that we can simply 
point to that for expansion.

On 8/28/2019 11:39 AM, Gorry Fairhurst wrote:
> Section 3.8.6.3 Delayed ACK.
> OLD:
>    and in a stream of full-sized segments there
>    SHOULD be an ACK for at least every second segment (SHLD-19).
> - Delayed ACK is specified in RFC1122 as: "...and in a stream of 
> full-sized segments there SHOULD be an ACK for at least every second 
> segment." Although correct, this does not specify a behaviour when 
> segments are not "full-sized". When asked by people, I have think this 
> should be something like:
> NEW:
> "the receiver SHOULD send an ACK when the data
> needing acknowledgment corresponds to no more than two full-sized 
> (MSS) segments."

---

From: David Borman <[email-masked]>
Date: Thu, 19 Dec 2019 16:31:28 -0600

Yes, the reality is that I don’t think any full featured TCP implementation today would want/be able to take advantage of this.  Some things were much simpler when RFC 1122 was published, a lot has changed since then.  But with IoT and very small and tiny TCP implementations, there may be some places where this makes sense.

I do agree with Gorry, rather than calling out a few example fields that also must not have changed, keep it simple:

If a retransmitted packet is identical to the original packet (which implies not only that the data boundaries have not changed, but also the headers have not changed),

		-David

> On Dec 19, 2019, at 11:47 AM, Michael Tuexen <[email-masked]> wrote:
>

---

From: Joe Touch <[email-masked]>
Date: Thu, 19 Dec 2019 18:44:33 -0800

FWIW, the ID is now supposed to be ignored if fragmentation isn’t possible (not source fragmented and not fragmentable).

Perhaps this advice needs revision accordingly, esp. since TCP generally tries to run in that mode.

I.e., retransmission should have no bearing on the IPv4 ID unless fragmentation occurs or is possible.

Joe

> On Dec 19, 2019, at 9:21 AM, David Borman <[email-masked]> wrote:
>

---

From: David Borman <[email-masked]>
Date: Fri, 20 Dec 2019 14:37:31 -0600

Yes, the IPID is only used for doing IP fragment reassembly, so the IPID really doesn’t matter on retransmission when IP fragmentation is not possible.

So just stating that the IPID must not be reused on retransmission unless the packet is identical to the original should be sufficient.  We want to avoid having an implementation reuse IPIDs and cause problems, and then say “but the RFC didn’t say we couldn’t do that”.
			-David

> On Dec 19, 2019, at 8:44 PM, Joe Touch <[email-masked]> wrote:
>

---

From: Joe Touch <[email-masked]>
Date: Fri, 20 Dec 2019 14:23:02 -0800

Hi, David, 

On 2019-12-20 12:37, David Borman wrote:

> Yes, the IPID is only used for doing IP fragment reassembly, so the IPID really doesn't matter on retransmission when IP fragmentation is not possible.

Right - it doesn't matter. But that also means it can be reused *even if
the packet contents change*. It should have no impact unless
fragmentation occurs; if it's "atomic" (not source fragmented and DF=0),
then it can be reused *at will* (and already widely is). 

> So just stating that the IPID must not be reused on retransmission unless the packet is identical to the original should be sufficient.

That's overkill. The ID can be (and already is) reused if the packets
are atomic (per above). 

> We want to avoid having an implementation reuse IPIDs and cause problems, and then say "but the RFC didn't say we couldn't do that".

Implementations of TCP need to know that they should not be using IP IDs
for uniqueness, as already indicated in RFC 6864. We should be clear in
supporting that advice here. 

Joe 

> FWIW, the ID is now supposed to be ignored if fragmentation isn't possible (not source fragmented and not fragmentable).
> 
> This has to do with the fact that the IPID field is used to do fragmentation reassembly.  It is ok to reuse the same IPID when retransmitting, as long as the retransmitted packet is identical to the original packet, not just the TCP data, but also all the TCP headers.  If the two packets aren't identical and they are fragmented, then using the same IPID could cause the receiver to not properly reassemble the packet.
> 
> What this also says is that, if a TCP implementation is such that it buffers up previously sent packets for possible retransmission and retransmits them verbatim, it doesn't have to change the IPID just because it is a retransmission.  But if there are any differences between the original and the retransmitted packet, then the IPID must be updated.
> 
> -David Borman
> 
> On 8/28/2019 11:39 AM, Gorry Fairhurst wrote: Section 3.8.1
> OLD:

---

From: Joe Touch <[email-masked]>
Date: Fri, 20 Dec 2019 17:00:38 -0800

Ps - make that DF=1

> On Dec 20, 2019, at 2:23 PM, Joe Touch <[email-masked]> wrote:
> 
> 
> Hi, David,
> 
> Right - it doesn't matter. But that also means it can be reused *even if the packet contents change*. It should have no impact unless fragmentation occurs; if it's "atomic" (not source fragmented and DF=0), then it can be reused *at will* (and already widely is).
>  
> That's overkill. The ID can be (and already is) reused if the packets are atomic (per above).
>  
> Implementations of TCP need to know that they should not be using IP IDs for uniqueness, as already indicated in RFC 6864. We should be clear in supporting that advice here.
>  
> Joe
>  
>  
>>  
>> 
>>             -David
>>