Re: [tcpm] TCP Tuning for HTTP

"Scharf, Michael (Michael)" <michael.scharf@alcatel-lucent.com> Fri, 06 November 2015 17:19 UTC

From: "Scharf, Michael (Michael)" <michael.scharf@alcatel-lucent.com>
To: Cory Benfield <cory@lukasa.co.uk>, Daniel Stenberg <daniel@haxx.se>, "tcpm@ietf.org Extensions" <tcpm@ietf.org>
Thread-Topic: TCP Tuning for HTTP
Thread-Index: AQHRGH8zEPMvd+b/q0yXA9NOzRbTi56OxJcAgAB2pJA=
Date: Fri, 06 Nov 2015 17:15:42 +0000
Message-ID: <655C07320163294895BBADA28372AF5D485417FE@FR712WXCHMBA15.zeu.alcatel-lucent.com>
References: <alpine.DEB.2.11.1511061128150.19082@tvnag.unkk.fr> <88103DD2-02E7-4265-BC2B-F4526A15FC54@lukasa.co.uk>
In-Reply-To: <88103DD2-02E7-4265-BC2B-F4526A15FC54@lukasa.co.uk>
Accept-Language: de-DE, en-US
Content-Language: de-DE
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/tcpm/ja7N3PPvfdbgne1LemDw_ccw3yM>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: [tcpm] TCP Tuning for HTTP
Precedence: list

Daniel, all,

I'd suggest to CC the tcpm list when discussing this draft. Basically all major TCP implementers monitor tcpm, and you should find useful expertise there. However, I am not sure whether all tcpm contributors love dancing ;)

Thanks

Michael


> -----Original Message-----
> From: Cory Benfield [mailto:cory@lukasa.co.uk]
> Sent: Friday, November 06, 2015 12:06 PM
> To: Daniel Stenberg
> Cc: HTTP Working Group
> Subject: Re: TCP Tuning for HTTP
> 
> 
> > On 6 Nov 2015, at 10:33, Daniel Stenberg <daniel@haxx.se> wrote:
> >
> > Hi friends!
> >
> > I've just submitted the 00-version of the document "TCP Tuning for
> HTTP"[1] and I will appreciate any and all sorts of feedback and
> additional good advice you can provide. The good ideas we need to tell
> our fellow HTTP implementers on how we poke on the TCP stack to make it
> dance for us.
> >
> > It is still a bit thin and there are some white spots in it. I'm
> counting on some help there! =)
> >
> > [1] = https://www.ietf.org/id/draft-stenberg-httpbis-tcp-00.txt
> 
> Daniel,
> 
> The first draft looks great! This is a really good start. I have a few
> small stylistic changes that I’ll propose as PRs to your repo, but
> wanted to add some more detail for stuff that seems missing or needs
> elaboration.
> 
> 1. net.core.somaxconn
> 
> I did some digging here because I was interested in how this interacted
> with the ‘backlog’ parameter to listen(). It seems that, on Linux,
> net.core.somaxconn represents the maximum value. This means that the
> maximum backlog on a listening socket is min(backlog, somaxconn). It
> would probably help to elaborate this section, but elaborating that
> section probably doesn’t make sense without also talking about the
> backlog argument to listen() itself. I’m willing to submit some text
> for that if you’re interested.
> 
> Your description of somaxconn (“the number of incoming TCP SYNs allowed
> to backlog”) is not actually accurate, I don’t think, because of the
> next section.
> 
> 2. tcp_max_syn_backlog
> 
> You don’t mention the setting related to net.core.somaxconn, which is
> net.ipv4.tcp_max_syn_backlog. somaxconn and the listen backlog on Linux
> apply to acknowledged connections (that is, the handshake is
> completed). tcp_max_syn_backlog applies to connections that have not
> yet been acknowledged by the client. I can’t find a corresponding IPv6
> setting, so we might need to do some more digging here to see if this
> is still used: does anyone else on this list know?
> 
> 3. Separate into client, server, and both optimisations.
> 
> Some of the optimisations and tweaks suggested here only make sense for
> servers (e.g. somaxconn), but some are good for both clients and
> servers. It would be good if we could call this out a bit more.
> 
> Otherwise, I’m really looking forward to seeing this develop!
> 
> Cory
> 
>

Re: [tcpm] TCP Tuning for HTTP Scharf, Michael (Michael)