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

[[e-mail]]

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

> 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: [e-mail]; 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:[e-mail]]
> Sent: Wednesday, March 02, 2016 6:47 AM
> To: HTTP WG
> Cc: [e-mail]; 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/
>
>
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm
>