Subject: [tcpm] Eifel on Windows stack

From: Yuchung Cheng <[email-masked]>
Date: Tue, 19 Jul 2016 11:08:58 +0200

First thanks for the presentation on W stack. For years it has remained
mysterious for many of us (at least myself). We had to use inference
technique to find Windows settings if they are not clearly publicly
documented. (e.g., delayed-ACK timeout)

Does Windows support RFC4015 and RFC3522, ie. cwnd undo, aka Eifel?

I am curiously its support in Windows (as well FreeBSD). TCP undo is one of
the most complicated esoteric code in Linux. It is somewhat helpful using
the TS-opt approach. The DSACK approach is not that useful but is more
complicated.

Also does Windows use the standard RTO formula (RFC6298)?

---

From: hiren panchasara <[email-masked]>
Date: Tue, 19 Jul 2016 09:22:46 -0700

(Quoting relevant message)
On 07/19/16 at 11:08P, Yuchung Cheng wrote:
> I am curiously its support in Windows (as well FreeBSD).

AFAIK, FreeBSD doesn't support Eifel detection/response.

Cheers,
Hiren

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Wed, 20 Jul 2016 23:03:57 +0200

Hello,

(First of all, and once again, thanks a lot for the great feedback
received about draft-gomez-core-tcp-constrained-node-networks-00.)

I would like to clarify one aspect with regard to a comment that was made
during the tcpm session on Monday. The comment was that "it is not a good
idea to keep long TCP connections for energy-constrained devices".

If an energy-constrained device does not use any energy saving mechanism,
the above statement is indeed correct. However, it is expected that such
devices will use techniques such as radio duty-cycling (often related with
MAC layer behavior) [1], which allow e.g. multiyear lifetime for devices
powered by a coin cell battery (of course, assuming the relatively
infrequent communication pattern typical of constrained node networks, and
with appropriate configuration).

Best regards,

Carles

[1] https://tools.ietf.org/html/draft-ietf-lwig-energy-efficient-04

---

From: Joe Touch <[email-masked]>
Date: Wed, 20 Jul 2016 14:39:30 -0700

> with appropriate configuration).
Idle TCP, without keepalives activated, is just state. Keeping it
"alive" doesn't "require" anything on such a device except low (or
no)-energy memory (e.g., flash).

The only issue is whether the device wants to continue interacting - it
is that desire, not anything about TCP, which would require leaving the
receive radio active.

Joe

---

From: Praveen Balasubramanian <[email-masked]>
Date: Tue, 26 Jul 2016 16:25:32 +0000

Cwnd undo is only supported via the F-RTO scheme. Eiffel is not supported. TCP Timestamps are disabled by default in Windows.

RFC 6298 is supported except for the change to the initial RTO from 3 seconds to 1 second. However there is a socket option SIO_TCP_INITIAL_RTO as well as a global setting which can be used to set the initial RTO to 1 second. Since Windows 8, Wininet uses this socket option to set initial RTO as 1 second and hence connections used by browsers and HTTP clients have lower SYN (and hence connect API) timeouts. Also, Windows does not revert to the 3 second initial RTO if the SYN has to be retransmitted.

From: Yuchung Cheng [mailto:[email-masked]]
Sent: Tuesday, July 19, 2016 2:09 AM
To: Praveen Balasubramanian <[email-masked]>
Cc: [email-masked] Extensions <[email-masked]>
Subject: Eifel on Windows stack

First thanks for the presentation on W stack. For years it has remained mysterious for many of us (at least myself). We had to use inference technique to find Windows settings if they are not clearly publicly documented. (e.g., delayed-ACK timeout)

I am curiously its support in Windows (as well FreeBSD). TCP undo is one of the most complicated esoteric code in Linux. It is somewhat helpful using the TS-opt approach. The DSACK approach is not that useful but is more complicated.