Subject: Call for Adoption: TCP Tuning for HTTP

From: Mark Nottingham <[email-masked]>
Date: Wed, 2 Mar 2016 16:46:30 +1100

[ 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: Willy Tarreau <[email-masked]>
Date: Wed, 2 Mar 2016 07:55:09 +0100

Hi Mark,

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

I definitely support this. Ideally it would evolve in the direction of
explaining a few shortcomings of TCP when used for HTTP and even suggest
a few implementation hints to prevent newcomers from falling into well
known traps (eg: avoid closing on the client first, or disable lingering
before closing to save the host from ending up with tons of time_wait
sockets that prevent new outgoing connections from being initiated).

I suspect we'll come to a point where people disagree on some settings,
which will be good since tuning is always a tradeoff. It means there
could be proposals for various use cases and their side effects.

I hope that ultimately this document could be referenced in future HTTP
specs so that we don't have to choose between explaining TCP out of
context and dropping the important explanations of some expected trouble.

Best regards,
Willy

---

From: Tim Wicinski <[email-masked]>
Date: Wed, 2 Mar 2016 02:59:03 -0500

I support this for adoption.

My only current comment is the draft currently does not seem to make any 
requirements (ala 2119).  When DNSOP revisited RFC5966 - DNS Transport 
over TCP - Implementation Requirements - last year
https://datatracker.ietf.org/doc/draft-ietf-dnsop-5966bis/

DNSOP was able to come to rough consensus on recommendations. I feel
httpbis can also come to such consensus.

I like BCP but I've gotten some pushback from my co-workers who feel 
it's too early in the /2 deployment for the best practices to be honed.

tim

---

From: Cory Benfield <[email-masked]>
Date: Wed, 2 Mar 2016 08:23:40 +0000

I support adopting this with a target of BCP.

Cory

> On 2 Mar 2016, at 05:46, Mark Nottingham <[email-masked]> wrote:
>

---

From: "Thomas Mangin" <[email-masked]>
Date: Wed, 02 Mar 2016 11:28:19 +0000

>   <https://tools.ietf.org/html/draft-stenberg-httpbis-tcp>

Hello,

The section about tcp_rmem could be extended to include some of the 
experience shared by Cloudflare:
https://blog.cloudflare.com/the-story-of-one-latency-spike/

Sincerely,

Thomas

---

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

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

Please comment on-list.

Regards,

---

From: Salvatore Loreto <[email-masked]>
Date: Sun, 6 Mar 2016 13:16:49 +0000

I definitely support this as BCP
 
I would love to see more focus on the mobile aspects especially the one
requiring different consideration and configuration  
Not sure the worth to distinguish between mobile wifi and cellular

Sal

-----Original Message-----
From: Mark Nottingham [mailto:[email-masked]] 
Sent: den 2 mars 2016 06:47
To: HTTP WG
Cc: [email-masked]; Daniel Stenberg
Subject: Call for Adoption: TCP Tuning for HTTP

Please comment on-list.

Regards,

---

From: Daniel Stenberg <[email-masked]>
Date: Sun, 6 Mar 2016 16:21:06 +0100 (CET)

On Sun, 6 Mar 2016, Salvatore Loreto wrote:

> requiring different consideration and configuration Not sure the worth to 
> distinguish between mobile wifi and cellular

(as writer of the draft in the subject)

If you can come up with specific suggestions for how to do that, I'll be all 
ears.

The flood of responses in this thread is excellent I think and truly shows 
that a document such as this could be useful. I've spent most of this week on 
skiis so I haven't really been able to respond to to suggestions and 
questions, but I hope to address some of those in the next few days.

But as always: please suggest your improvements or additions on-list and I'll 
try to collect them and make another version available soon.

-- 

  / daniel.haxx.se

---

From: Leif Hedstrom <[email-masked]>
Date: Sun, 6 Mar 2016 18:17:11 -0700

> On Mar 1, 2016, at 10:46 PM, Mark Nottingham <[email-masked]> wrote:
> 

+1 on adopting this as a BCP.

I think its focus / bias towards Linux has to be addressed, which requires input / feedback from other OS vendors of course. But the adoption of this draft would likely help such efforts significantly.

Cheers,

— leif

---

From: Amos Jeffries <[email-masked]>
Date: Mon, 7 Mar 2016 15:08:01 +1300

On 7/03/2016 2:17 p.m., Leif Hedstrom wrote:
> 
>> On Mar 1, 2016, at 10:46 PM, Mark Nottingham wrote:
>>

+1 "me too".

In regards to OS-specific things, I am somewhat against making it have
any at all. The most desirable outcome of this draft would not be that
admin can find what to tune for HTTP, but that TCP would evolve so we
dont have to tune at all. Don't forget that HTTP applications require
many different protocols all working together over the same transport(s)
to be efficient. Tuning just for one wont help much.

Along the lines of the FQ-Codel work done by the buffer bloat guys (some
of what will be relevant here) having a strong and fair underlying
transport can make the whole system more efficient.

Amos

---

From: Leif Hedstrom <[email-masked]>
Date: Tue, 8 Mar 2016 15:48:09 -0700

> On Mar 6, 2016, at 7:08 PM, Amos Jeffries <[email-masked]> wrote:
> 

Good point. I think “none" is better than "just Linux", which would force the authors to describe each option in a TCP and protocol standards way (and not implementation specific). Sounds like a lot of work though.

That much said, that might turn it into a difficult document to read. In the end, what many people need is a single sysctl.conf (etc.) file to deploy. :-).

Cheers,

— Leif

---

From: Joe Touch <[email-masked]>
Date: Tue, 8 Mar 2016 15:07:55 -0800

On 3/8/2016 2:48 PM, Leif Hedstrom wrote:
> That much said, that might turn it into a difficult document to read. In
> the end, what many people need is a single sysctl.conf (etc.) file to
> deploy. :-).

That is not the purpose of RFCs.

That is the purpose of manual pages.

Joe

---

From: Matthew Kerwin <[email-masked]>
Date: Wed, 9 Mar 2016 09:09:24 +1000

On 09/03/2016 8:54 AM, "Leif Hedstrom" <[email-masked]> wrote:
>
> Good point. I think “none" is better than "just Linux", which would force
the authors to describe each option in a TCP and protocol standards way
(and not implementation specific). Sounds like a lot of work though.
> — Leif

Make the main prose TCP-pure and hard to read, then whack in some "example"
appendices/subsections showing how to do it in common implementations/OSes.
If the emphasis is right (that the prose is canon, the examples are
illustrative), it should work well.

---

From: Daniel Stenberg <[email-masked]>
Date: Wed, 16 Mar 2016 14:44:08 +0100 (CET)

On Wed, 2 Mar 2016, Scharf, Michael (Nokia - DE) wrote:

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

Several? I can only find one reference, and that is to Tail Loss Probe in a 
section that is still to be written/ripped out.

Does anyone have any particular advice when it comes to tail loss and HTTP/TCP 
that we should put there?

-- 

  / daniel.haxx.se

---

From: Daniel Stenberg <[email-masked]>
Date: Wed, 16 Mar 2016 14:49:00 +0100 (CET)

> distinguish between mobile wifi and cellular

Any chance you can expand on what that "more focus" would entail? I certainly 
think it would be great to be able to cover that ground as well, but I'll need 
help.

-- 

  / daniel.haxx.se