Subject: [tcpm] 793bis: requirement on RTO computation

From: Wesley Eddy <[email-masked]>
Date: Mon, 12 Dec 2016 15:04:06 -0500

This is a thread to check group consensus on how to discuss RTT 
estimation and RTO computation in RFC 793bis.

RFC 793 originally had some material on this, described as "An Example 
Retransmission Timeout Procedure", but that is replaced by several later 
documents.
- RFC 1122 adds mention of Karn's algorithm plus exponential backoff of 
the RTO, and more strongly adds requirements ("MUST") for these, rather 
than just being an "example".
-  RFC 2988 and then 6298 expanded on RTT and RTO computation, and 6298 
currently updates 1122 in this regard.

I think 6298 is "not too long" and has clear requirements.  I think 
793bis should simply reference 6298 as the requirement for computation 
of the RTO, rather than trying to actually discuss this as a 
self-contained topic in 793bis.  I think that would be duplicative, 
unnecessary, and confusing.

Do people agree with this?

For reference, the current 793bis text is below.  The first paragraph is 
direct from 793, the fourth from 1122, and the text in-between is 
attempting to say what I described above:

3.8.1.  Retransmission Timeout

    Because of the variability of the networks that compose an
    internetwork system and the wide range of uses of TCP connections the
    retransmission timeout (RTO) must be dynamically determined.

    The RTO MUST be computed according to the algorithm in [7], including
    Karn's algorithm for taking RTT samples.

    RFC 793 contains an early example procedure for computing the RTO.
    This was then replaced by the algorithm described in RFC 1122, and
    subsequently updated in RFC 2988, and then again in RFC 6298.

    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).

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 12 Dec 2016 12:14:29 -0800

On Mon, Dec 12, 2016 at 12:04 PM, Wesley Eddy <[email-masked]> wrote:

> This is a thread to check group consensus on how to discuss RTT estimation
> and RTO computation in RFC 793bis.
>
> I think 6298 is "not too long" and has clear requirements.  I think 793bis
> should simply reference 6298 as the requirement for computation of the RTO,
> rather than trying to actually discuss this as a self-contained topic in
> 793bis.  I think that would be duplicative, unnecessary, and confusing.
>

+1. Nobody refers to 793 for RTT/RTO computation anyways.

- jana

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

---

From: Yuchung Cheng <[email-masked]>
Date: Mon, 12 Dec 2016 12:24:39 -0800

On Mon, Dec 12, 2016 at 12:04 PM, Wesley Eddy <[email-masked]> wrote:
>
> This is a thread to check group consensus on how to discuss RTT estimation and RTO computation in RFC 793bis.
>
> RFC 793 originally had some material on this, described as "An Example Retransmission Timeout Procedure", but that is replaced by several later documents.
> - RFC 1122 adds mention of Karn's algorithm plus exponential backoff of the RTO, and more strongly adds requirements ("MUST") for these, rather than just being an "example".
> -  RFC 2988 and then 6298 expanded on RTT and RTO computation, and 6298 currently updates 1122 in this regard.
>
> I think 6298 is "not too long" and has clear requirements.  I think 793bis should simply reference 6298 as the requirement for computation of the RTO, rather than trying to actually discuss this as a self-contained topic in 793bis.  I think that would be duplicative, unnecessary, and confusing.
>
> For reference, the current 793bis text is below.  The first paragraph is direct from 793, the fourth from 1122, and the text in-between is attempting to say what I described above:
>
What will the new text looks like in the bis?

---

From: Neal Cardwell <[email-masked]>
Date: Mon, 12 Dec 2016 15:34:45 -0500

On Mon, Dec 12, 2016 at 3:14 PM, Jana Iyengar <[email-masked]> wrote:

>> 793bis should simply reference 6298 as the requirement for computation of
>> the RTO, rather than trying to actually discuss this as a self-contained
>> topic in 793bis.  I think that would be duplicative, unnecessary, and
>> confusing.
>>

+1 for just citing 6298, with text along the proposed lines.

neal

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Mon, 12 Dec 2016 20:41:52 +0000

Hi all,

May I rephrase the question a bit: Should the reference to RFC 6298 be a MUST?

For what it is worth, I can hardly think of any reason why we would want to duplicate text RTO in 793bis, so IMHO the reference wording seems the key question.

Michael

> -----Original Message-----
> From: tcpm [mailto:[email-masked]] On Behalf Of Wesley Eddy
> Sent: Monday, December 12, 2016 9:04 PM
> To: [email-masked]
> Subject: [tcpm] 793bis: requirement on RTO computation
>

---

From: Yuchung Cheng <[email-masked]>
Date: Mon, 12 Dec 2016 15:08:15 -0800

>> Do people agree with this?
+1 but some small suggestions below
>>     Karn's algorithm for taking RTT samples.
why not just s/[7]/RFC6298  to save reader a round trip b/c he almost
has to know what that is.

>>     Section 3.2.1.5 of RFC 1122).
is this ipid text still useful. The text in RFC1122 seems to suggest
the RFC authors
didn't even believe that re-assembly benefit.

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 12 Dec 2016 15:17:11 -0800

> May I rephrase the question a bit: Should the reference to RFC 6298 be a

Good question. MUST seems too strong for the reference to 6298, and there
are no interoperability issues by doing something different. I wonder what
folks think about saying "SHOULD implement 6298, and MUST adhere to
guidelines in draft-ietf-tcpm-rto-consider".

> For what it is worth, I can hardly think of any reason why we would want
> to duplicate text RTO in 793bis, so IMHO the reference wording seems the
> key question.
>
> Michael
>
>

---

From: "Richard Scheffenegger" <[email-masked]>
Date: Tue, 13 Dec 2016 10:06:58 +0100

Hi Neal,

did you have time to glance over the timestamp negotiation draft? 

Here is a brief abstract of some of the properties that the proposed negotiation scheme offers. However, at the time, there was too little interest in this (and no other vendor to support development efforts) thus it expired.

a) no additional TCP Option space useage, particular in the initial SYN

b) Up to 24 bits for arbitrary signalling - the draft uses 16 (https://tools.ietf.org/html/draft-scheffenegger-tcpm-timestamp-negotiation-05) to signal the timestamp interval; the value is encoded differently from a IEEE floating point representation to allow further freedom to indicate relative precision of the injected timestamp (ie. envision a NIC capable of hw clocking each segment in a TSO transfer, vs. using a coarse grained software clock in a virtual host)

c) generic mechanism to make (parts of) the  timestamp useful for the receiver, allowing the sender to weakly authenticate returned timestamps (e.g. avoiding the cubic epoch exploit to game a sender by manipulating timestamps)

d) In that basic version, 8 bits would still be available to provide the signals envisioned by your proposal for indicating Max ACK Delay - perhaps using a shift value offset by a constant biad as for the timestamp interval, more granualar signaling would be possible than in your proposal.

Drawback of the scheme: duing 3WHS, the sender needs to keep state of the original TSval (which should be a non-issue for Linux stacks, and is manageable for byte-oriented stacks).

Also, a small probability of falsely activating the TS negotiation. However, against servers on the internet, this probability is smaller than expected as TSval still relates linearly to system uptime, in most implementations; I've investigated this during writing intensively (not what you could do, though) - see section 5.3 

Re-reading, I see that my descriptive language  is perhaps not clear enough, the signals spoken about in the draft are always exchanged in a TSecr field of a TS Option, with the TSecr of the SYN/ACK being the XOR sum of the TSval from the SYN, plus the capabilites signal of the receiver...

Best regards,
  Richard

Great. Thanks, Bob. We'll take a look at these...

neal

On Wed, Nov 16, 2016 at 9:59 AM, Bob Briscoe <[email-masked]> wrote:

> Neil, [re-sending from correct address, so it is acceptable to the tcpm
> list]
>
> As promised in the discussion just now about your timer negotiation talk
> in tcpm, here's the previous draft on a similar subject:
> Additional negotiation in the TCP Timestamp Option field during the TCP
> handshake
> <https://tools.ietf.org/html/draft-scheffenegger-tcpm-timestamp-negotiation-05>
>
> This was originally prompted by the research here (see section 3.1 for the
> timestamp discussion), which you might also be interested in:
> Chirping for Congestion Control - Implementation Feasibility
> <http://www.bobbriscoe.net/pubs.html#chirp_impl>
>
>
>
> Bob
>
> PS. I can recommend a good search engine to find stuff like this :)
>
>
> --
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/
>
>

---

From: Neal Cardwell <[email-masked]>
Date: Wed, 14 Dec 2016 11:42:02 -0500

Hi Richard,

Thanks for your note. Unfortunately, I've been busy with other projects
recently (largely BBR) and haven't had time to read your draft on improving
timestamps (draft-scheffenegger-tcpm-timestamp-negotiation-05). It looks
like a very nice, thorough draft. So, rest assured that I will read it
before our team embarks on any draft related to the timestamp code we are
running within Google (which was written by Eric Dumazet, cc-ed).

thanks,
neal

On Tue, Dec 13, 2016 at 4:06 AM, Richard Scheffenegger <[email-masked]>
wrote:

> Here is a brief abstract of some of the properties that the proposed
> negotiation scheme offers. However, at the time, there was too little
> interest in this (and no other vendor to support development efforts) thus
> it expired.
>
> b) Up to 24 bits for arbitrary signalling - the draft uses 16 (
> https://tools.ietf.org/html/draft-scheffenegger-tcpm-
> timestamp-negotiation-05) to signal the timestamp interval; the value is
> encoded differently from a IEEE floating point representation to allow
> further freedom to indicate relative precision of the injected timestamp
> (ie. envision a NIC capable of hw clocking each segment in a TSO transfer,
> vs. using a coarse grained software clock in a virtual host)
>
> c) generic mechanism to make (parts of) the  timestamp useful for the
> receiver, allowing the sender to weakly authenticate returned timestamps
> (e.g. avoiding the cubic epoch exploit to game a sender by manipulating
> timestamps)
>
> d) In that basic version, 8 bits would still be available to provide the
> signals envisioned by your proposal for indicating Max ACK Delay - perhaps
> using a shift value offset by a constant biad as for the timestamp
> interval, more granualar signaling would be possible than in your proposal.
>
>
> Drawback of the scheme: duing 3WHS, the sender needs to keep state of the
> original TSval (which should be a non-issue for Linux stacks, and is
> manageable for byte-oriented stacks).
>
> Also, a small probability of falsely activating the TS negotiation.
> However, against servers on the internet, this probability is smaller than
> expected as TSval still relates linearly to system uptime, in most
> implementations; I've investigated this during writing intensively (not
> what you could do, though) - see section 5.3
>
> Re-reading, I see that my descriptive language  is perhaps not clear
> enough, the signals spoken about in the draft are always exchanged in a
> TSecr field of a TS Option, with the TSecr of the SYN/ACK being the XOR sum
> of the TSval from the SYN, plus the capabilites signal of the receiver...
>
> Best regards,
>   Richard
>
>
>
>