RE: TCP Tuning for HTTP

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

Received on Friday, 6 November 2015 17:18:34 UTC