RE: TCP Tuning for HTTP

["Scharf, Michael (Michael)" <[e-mail]>]

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:[e-mail]]
> 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 <[e-mail]> 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
> 
>