Subject: Re: [tcpm] 793bis: delayed ACKs

From: Yuchung Cheng <[email-masked]>
Date: Fri, 3 Jan 2020 13:30:43 -0800

On Thu, Dec 19, 2019 at 2:06 PM Wesley Eddy <[email-masked]> wrote:
>
> 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.
Beside that, perhaps it is worth some additional text on real
practices. With GRO, ACK decimation/compression in the network and in
the host, ACKs are greatly stretched (tens of full-size segments) for
performance reasons. It would only be more common w/ ever faster
networks.

>
>
> 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."
>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Fernando Gont <[email-masked]>
Date: Wed, 22 Jan 2020 15:54:37 -0300

Hello, Wes,

On 18/12/19 18:33, Wesley Eddy wrote:
> 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.

My response to Gorry in-line:

>> OLD, Section: "   The TCP Quiet Time Concept"
>> - Found this section quite amusing. Is this concept widely implemented 
>> in stacks?

No.

>> - 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?

Unless I'm missing something, MSL implies the value specified in this 
spec. -- so there's no need to guess or "know" more than that.

(the real MSL is kind of tricky since, in theory, it is derived from the 
IPv4 Time to Live. You might know the TTL *you* use, but you probably 
won't know the TTL that other remote TCPs had employed. So, strictly 
speaking, in order to be safe you'd have to wait 255 seconds).

>> - To me, this section raises many questions about whether this is best 
>> current practice. 

AFAIK, it has never been a "best current practice". That said, you need 
the "quiet time concept" from a "correctness" point of view. -- 
otherwise the TCP SEQ takes care of old segments of the same incarnation 
of the connection, but not of old segments from a *previous* incarnation 
of the connection.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Fernando Gont <[email-masked]>
Date: Wed, 22 Jan 2020 16:05:31 -0300

Hi, Dave,

On 20/12/19 17: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.

Some boxes are know to clear DF and fragment packets. That's why some 
implementations have resorted to ensure IP ID uniqueness (or try to), 
even when they send packets with DF=1.

Thanks,

---

From: Joe Touch <[email-masked]>
Date: Wed, 22 Jan 2020 17:08:12 -0800

> On Jan 22, 2020, at 11:05 AM, Fernando Gont <[email-masked]> wrote:
> 
> Some boxes are know to clear DF and fragment packets. That's why some implementations have resorted to ensure IP ID uniqueness (or try to), even when they send packets with DF=1.

True, but equally true that devices reuse the ID when the packet is atomic (not already fragmented and DF=1), as noted in RFC 6864. That RFC deprecated use of the IPv4 ID except for reassembly.

There is no similar deprecation of the need for intermediate devices to honor DF.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 22 Jan 2020 22:27:04 -0800

> On Jan 22, 2020, at 10:54 AM, Fernando Gont <[email-masked]> wrote:
> 
>>> - Found this section quite amusing. Is this concept widely implemented in stacks?
> 
> No.

It might be useful to consider this is relevant only for systems that reboot in under 2 MSL anyway. That’s a good reason most systems don’t need to care - but a good reason to worry about ignoring this issue as we move forward.

I.e., of this concept and its utility, as financial investors advise:

	Past performance is not be a predictor of future results.

Joe

---

From: Matt Mathis <[email-masked]>
Date: Wed, 22 Jan 2020 22:59:06 -0800

There are two other changes that have largely made this problem moot:
a) ISS and ephemeral port randomization make it extremely unlikely that
segments delayed across a reboot will be in sequence for any connections
(at the time this was written, both ISS and ephemeral ports were generated
by counters starting from fixed integers).
b) Although not reflected in policy, the effective MSL of the internet has
been declining as it gets faster.   There are paths and devices that can
delay packets by more than 10 seconds but they don't normally cause packets
to be reordered by that much, so a new SYN can't pass an old data segment,
which is a requirement for triggering the hazard.

I would suggest changing the text to say "a theoretical problem....  that
could be fixed by...  but for the following reasons it is viewed as being
sufficiently unlikely to ignore.

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.

On Wed, Jan 22, 2020 at 10:27 PM Joe Touch <[email-masked]> wrote:

> It might be useful to consider this is relevant only for systems that
> reboot in under 2 MSL anyway. That’s a good reason most systems don’t need
> to care - but a good reason to worry about ignoring this issue as we move
> forward.
>

---

From: Fernando Gont <[email-masked]>
Date: Thu, 23 Jan 2020 03:52:27 -0300

On 23/1/20 03:27, Joe Touch wrote:
> 
> 
>> On Jan 22, 2020, at 10:54 AM, Fernando Gont <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
> reboot in under 2 MSL anyway. That’s a good reason most systems don’t 
> need to care - but a good reason to worry about ignoring this issue as 
> we move forward.
> 

I agree.

That said, in virtualized environments, and also in many (most?) modern 
envirnonments, you normally get to bootstrap in less than MSL.

As noted, I wouldn't remove the "quiet time concept", since it has to do 
with correctness of the spec (it is the only way to answer the question 
"how do you take care of stale segments from previous incarnations of a 
connection?").

That said, I find it quite unlikely that OSes try to implement the Quite 
Time Concept -- even for the cases where it would be required. 
Particularly if they can get away with it, for practical purposes, by 
means of TCP timestamps.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 23 Jan 2020 04:20:08 -0300

On 23/1/20 03:59, Matt Mathis wrote:
> (at the time this was written, both ISS and ephemeral ports were 
> generated by counters starting from fixed integers).

FWIW, note in many of the randomization schemes (e.g. RFC6528) the 
resulting sequence still looks like a counter for each (src, dst). 
Still, I would expect the problem to be unlikely.

> b) Although not reflected in policy, the effective MSL of the internet 
> has been declining as it gets faster.   There are paths and devices that 
> can delay packets by more than 10 seconds but they don't normally cause 
> packets to be reordered by that much, so a new SYN can't pass an old 
> data segment, which is a requirement for triggering the hazard.

Agreed.

> I would suggest changing the text to say "a theoretical problem....  
> that could be fixed by...  but for the following reasons it is viewed as 
> being sufficiently unlikely to ignore.

I would agree with this. That aside, one might also consider than as 
encryption becomes more pervasive, even in the case the problem took 
place, the connection would be reset, and the application would recover. 
  -- so I guess it would be a hard case to make OSes implement this 
"quiet time".

Thanks,

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 23 Jan 2020 13:24:47 +0000

I think this is the wrong ID to discuss anything related to IPv4 ID.

I suspect some deployed boxes do exist that do shortest-packet first 
link scheduling; re-use various codepoints; and boxes that in this case 
clear DF. That's sad, but real. In days gone by, people may have built 
implementations that relied on any of these. It doesn't mean a modern 
TCP Spec needs to discuss the IPv4 ID field.

I'd encourage the TCP Spec to say nothing about how IPv4 uses the ID field.

Gorry

On 22/01/2020 19:05, Fernando Gont 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.
>

---

From: Fernando Gont <[email-masked]>
Date: Thu, 23 Jan 2020 11:13:16 -0300

> I'd encourage the TCP Spec to say nothing about how IPv4 uses the ID field.

+1

THanks,

---

From: Joe Touch <[email-masked]>
Date: Thu, 23 Jan 2020 06:54:47 -0800

> On Jan 23, 2020, at 5:24 AM, Gorry Fairhurst <[email-masked]> wrote:
> 

I disagree. 

It’s important to support the *requirement* in 6864 by explicitly indicating that the ID *MUST NOT* be used for duplicate segment detection in TCP.

It’s not enough to simply ignore the issue. We can’t fix incorrect implementations unless we have something to back it up.

joe

---

From: Fernando Gont <[email-masked]>
Date: Fri, 24 Jan 2020 01:58:56 -0300

> It’s important to support the *requirement* in 6864 by explicitly indicating that the ID *MUST NOT* be used for duplicate segment detection in TCP.

With layering in mind, why would one want to do that?

Thanks,

---

From: Joe Touch <[email-masked]>
Date: Thu, 23 Jan 2020 21:48:55 -0800

> On Jan 23, 2020, at 8:58 PM, Fernando Gont <[email-masked]> wrote:
> 

Because the information in RFC1122 in section 4.2.2.15 needs to be integrated and corrected to bring it up to date with RFC6864, even if in the negative.

I.e., this doc should be very clear on two points:

	- TCP MUST NOT attempt to control the IP ID to try to indicate duplicate sent segments
	- TCP MUST NOT use the IP ID in trying to identify duplicate received segments

I.e., in summary, exactly to encode that layering.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Fri, 24 Jan 2020 03:08:36 -0300

On 24/1/20 02:48, Joe Touch wrote:
> 
> 
>> On Jan 23, 2020, at 8:58 PM, Fernando Gont <[email-masked] 
>>>> On Jan 23, 2020, at 5:24 AM, Gorry Fairhurst <[email-masked] 
>>>> <mailto:[email-masked]>> wrote:
>>>>
>>> It’s important to support the *requirement* in 6864 by explicitly 
>>> indicating that the ID *MUST NOT* be used for duplicate segment 
>>> detection in TCP.
>>
> Because the information in RFC1122 in section 4.2.2.15 needs to be 
> integrated

Does it? It would seem to me that these IP ID tricks are an 
implementation-specific trick that would never be implemented in 
general-purpose implementations.

Even more, it would make even less sense in the light of the Internet 
moving towards IPv6 (albeit at a horrible pace), wheere the "IP ID" is 
not available in all packets.

> and corrected to bring it up to date with RFC6864, even if in 
> the negative.
> 

My question here is whether we want to drag such (mostly obsolete) 
details into this more modern spec, or not.

It would seem yo me that a fresh reader of *this* 793bis would probably 
be quite puzzled when reading this sort of requirement that mostly have 
to do with what some implementations did ages ago...

---

From: Joe Touch <[email-masked]>
Date: Fri, 24 Jan 2020 06:50:12 -0800

Text is needed here to deal with the current text in 1122. 793bis doesn’t exist in a vacuum.

Joe

> On Jan 23, 2020, at 10:08 PM, Fernando Gont <[email-masked]> wrote:
> 
>>> On Jan 23, 2020, at 8:58 PM, Fernando Gont <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>>>> On Jan 23, 2020, at 5:24 AM, Gorry Fairhurst <[email-masked] <mailto:[email-masked]>> wrote:
>>>>> 
>> Because the information in RFC1122 in section 4.2.2.15 needs to be integrated
> 
> Does it? It would seem to me that these IP ID tricks are an implementation-specific trick that would never be implemented in general-purpose implementations.
> 
> Even more, it would make even less sense in the light of the Internet moving towards IPv6 (albeit at a horrible pace), wheere the "IP ID" is not available in all packets.
> 
> 
>> and corrected to bring it up to date with RFC6864, even if in the negative.
> My question here is whether we want to drag such (mostly obsolete) details into this more modern spec, or not.
> 
> It would seem yo me that a fresh reader of *this* 793bis would probably be quite puzzled when reading this sort of requirement that mostly have to do with what some implementations did ages ago...
> 
> 
> -- 
> Fernando Gont
> SI6 Networks