Subject: [tcpm] FW: Call for Adoption: TCP Tuning for HTTP

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Wed, 2 Mar 2016 09:39:47 +0000

I assume this could be of interest to the TCPM community.

Michael

-----Original Message-----
From: Scharf, Michael (Nokia - DE) 
Sent: Wednesday, March 02, 2016 10:37 AM
To: 'Mark Nottingham'; HTTP WG
Cc: [email-masked]; Daniel Stenberg
Subject: RE: Call for Adoption: TCP Tuning for HTTP

The document refers to several TCPM RFCs with experimental status, e.g., in Section 3. That may have to be taken into account when heading towards BCP status.

Michael
(TCPM co-chair)

-----Original Message-----
From: Mark Nottingham [mailto:[email-masked]] 
Sent: Wednesday, March 02, 2016 6:47 AM
To: HTTP WG
Cc: [email-masked]; Daniel Stenberg
Subject: Call for Adoption: TCP Tuning for HTTP

[ copying Alison as our Transport Tech Advisor ]

Daniel has kindly started a document about how HTTP uses TCP, both for /1 and /2:
  <https://tools.ietf.org/html/draft-stenberg-httpbis-tcp>

We haven't explicitly discussed this at a meeting, but I have heard interest in this topic from a variety of folks.

What do people think about adopting this with a target of Best Current Practice?

Please comment on-list.

Regards,

--
Mark Nottingham   https://www.mnot.net/

---

From: [email-masked]
Date: Wed, 2 Mar 2016 11:12:07 -0000

I read the previous version, and I think this document needs to be talked
about in TCPM. Some people may find it useful to have a document to point
toIETF consensus on what to tune in the stack for HTTP.

I do think this document needs to be talked about in TCPM.

To me there are several parts to this document that appear to encourage a
change the default behaviour of TCP. If this is published as a BCP, I
think it needs to be aligned to current published RFCs, and describe the
trade-offs that need to be considered.

A few examples:

“2.5.  Lower the TCP FIN timeout

   High connection completion rates will consume ephemeral ports
   quickly.  Lower the time during which connections are in FIN-WAIT-2/
   TIME_WAIT states so that they can be purged faster and thus maintain
   a maximal number of available sockets.  The primitives for the
   assignment of these values were described in [RFC0793], however
   significantly lower values are commonly used.”

- This also has significant impact on the robustness of TCP in the face of
deadly and reordering.  I wonder, has this been discussed somewhere from a
robustness/security perspective? It seems like the proposed BCP text
encourages tuning without at the moment any suggestion of safe values.

 “2.6.  Reuse sockets in TIME_WAIT state

   When running backend servers on a managed, low latency network you
   might allow the reuse of sockets in TIME_WAIT state for new
   connections when a protocol complete termination has occurred.  There
   is no RFC that covers this behaviour.”

- TIME-WAIT state that prevents delayed segments from one connection
instance from interfering with a later one.  Applications that are aware
of and designed for this behavior can shift maintenance of the TIME-WAIT
state to conserve resources by controlling which end closes a TCP
connection, etc. Similarly, the current text could encourage a method that
could be thought to be unsafe for general Internet deployment, without
explaining this.

“3.1.  TCP Fast Open”
- I think a BCP would need to note the experimental status of this RFC.

“3.2.  Initial Congestion Window”
- I think a BCP would need to note the experimental status of this RFC. In
addition, I’m concerned about the final sentence:

“   IW10 has been reported to perform fairly well even in high volume
   servers.”
- In a BCP, this would sound like a new recommendation, but it seems lot
me to be a stronger claim than the RFC itself. There are side effects to
raising IW on other traffic crossing slower bottlenecks, and known
mitigations, such as pacing.

“4.3.  Nagle's Algorithm”
- True disabling for HTTP is likely to help - However, this remains an
option because it has significant performance benefits for low-speed
bottlenecks. I think text needs to be clear on the trade-off. It would be
nice to state the trade-off.

“4.4.  Keep-alive” - This maybe is confusing, to me, keep alive in TCP is
important to TCP to verify a path is operational, rather than to keep a
middle box happy. If it’s the latter, perhaps should likely need to refer
to the behave RFCs??

“5.1.  Slow Start after Idle

   Slow-start is one of the algorithms that TCP uses to control
   congestion inside the network.  It is also known as the exponential
   growth phase.  Each TCP connection will start off in slow-start but
   will also go back to slow-start after a certain amount of idle time.

   In Linux systems you can prevent the TCP stack from going back to
   slow-start after idle by settting
   net.ipv4.tcp_slow_start_after_idle = 0”

- And TCPM has just published RFC7661 on this topic. I’m concerned the
proposed text doesn’t make the recommendations of the IETF clear.
Disabling slow-start-after-idle is possible in a stack, but is there an
RFC that shows transport community consensus that we should recommend
disabling? or caution about the implications?

I’m not quite sure what the presented message is on timers, but again the
values described in the IETF series appear not to be noted in the current
version.

Gorry

> The document refers to several TCPM RFCs with experimental status, e.g.,
> in Section 3. That may have to be taken into account when heading towards
> BCP status.
>
> Michael
> (TCPM co-chair)
>
>
> We haven't explicitly discussed this at a meeting, but I have heard
> interest in this topic from a variety of folks.
>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: Joe Touch <[email-masked]>
Date: Wed, 2 Mar 2016 12:25:07 -0800

> I assume this could be of interest to the TCPM community.

I have doubts:

- it reads like a Linux manual page

	All Linux-specific references and commands would need to be
	moved to an appendix to be useful as an RFC.

- this repeats (sometimes correctly, sometimes in error) existing advice

J. Heidemann, K. Obraczka, J. Touch, “Modeling the Performance of HTTP
Over Several Transport Protocols,” IEEE/ACM Transactions on Networking,
V5, N5, Oct. 1997, pp.616-630.

T. Faber, J. Touch, and W. Yue, “The TIME-WAIT state in TCP and Its
Effect on Busy Servers,” in Proc. IEEE Infocom, 1999, pp. 1573-1583.

- it has significant errors

	TIME-WAIT issues apply to servers, not clients.

	Nagle has been known to perform poorly for multibyte
	interactive traffic for a very long time, including not
	only web traffic but also multi-byte character or keyboard
	signals.

	Disabling slow-start after idle is safe only with pacing.
	Without pacing, the resulting traffic can generate a burst
	that was never experienced and result in both poor performance
	for the current connection and potential impact to competing
	traffic.

(those are just a few)

Overall, I think a man page might be useful, but this summary isn't
useful for the IETF.

Joe

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Wed, 2 Mar 2016 20:36:08 +0000

For the moment, I suggest to direct specific comments on the I-D to the HTTPbis list.

I am not at all involved in this document and this adoption call. I just found that e-mail this morning in my inbox.

Michael