Re: [tcpm] TCP Tuning for HTTP - update

[Yuchung Cheng <[e-mail]>]

On Thu, Aug 18, 2016 at 9:54 AM, Gorry Fairhurst <[e-mail]>
wrote:

> Speaking as someone who commented on an earlier version:
>
> I think it is good to offer advice on how TCP is used for web traffic. I
> can see there is likely useful information that can document how some
> things are done, and perhaps also recommend some changes. I support
> continuing work on this.
>
> Publishing a document like this in the RFC series needs to be consistent
> with IETF consensus. The ID touches on many things that are assigned to
> TCPM. (The breadth of topics may be a good reason for a document - but is
> also a concern, because many things need more clear description before the
> recommendations become clear).
>
> I think this document should NOT be considered as BCP. It talks about
> system configuration of endpoints, and of the recommendations I see, some
> do support current PSs, some set new precedents against current PS RFCs and
> in some cases the present text appears to endorse EXP RFCs. If published as
> a BCP, that sort of advice is likely to be confusing. Such information can
> also easily be outdated, I suggest if adopted, this should be Informational
> and clearly set the scope of the recommendations.
>
+1 on informational

It'd be great for the document to cite more detailed technical reports, for
readers to learn the pros and cons, and the history. IMO it'd significantly
improve this document. The reason is that TCP and network will continue to
evolve, so knowing the past and details can help readers to judge whether a
specific recommendation is still useful or not, if he is willing to spend
time to explore. For example, he can use some online tools to track the
citation of these reports and see new reports.

For the document, I'd recommend two more items that my personal experience
gives remarkable performance enhancement on reducing and recover from
losses.

1) make sure your stack supports SACK
2) enable pacing.

On disabling Nagle, there are also better APIs like Linux Cork so you don't
have to send small packets even on continuous writes. One common problem I
often see is developers unconditionally disable Nagle, but their HTTP
workload may lead to lots of small packets.

my 2c


> If this work continues, it needs to be reviewed by TCPM and HTTPbis. This
> would need much more than simply a last-call in both working groups - but
> I'm sure with proper coordination progress could be made so that there were
> no surprises for either group at the time of WGLC!
>
> Gorry
>
>
>
>
>> -----Original Message-----
>> From: tcpm [mailto:[e-mail]] On Behalf Of Mark Nottingham
>> Sent: Wednesday, August 17, 2016 4:03 AM
>> To: [e-mail]
>> Cc: Patrick McManus; Daniel Stenberg
>> Subject: [tcpm] TCP Tuning for HTTP - update
>>
>> Hi TCPM,
>>
>> Just a quick note; Daniel and Tim have made an update to the TCP Tuning
>> for HTTP draft:
>>   https://tools.ietf.org/html/draft-stenberg-httpbis-tcp
>>
>> We've had a Call for Adoption open for this draft for a while, and will
>> likely adopt it soon. However, we'd like to get feedback from this
>> community first -- both about the latest version of the input document, and
>> to see if there's interest in helping out.
>>
>> You can give feedback on the HTTP WG mailing list <
>> https://lists.w3.org/Archives/Public/ietf-http-wg/>, or  by responding
>> to this e-mail (Please leave the CC line; Patrick and I will try to
>> summarise the feedback to the WG).
>>
>> Cheers,
>>
>> --
>> Mark Nottingham   https://www.mnot.net/
>>
>>
>>
>>
>> _______________________________________________
>> tcpm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tcpm
>>
>> _______________________________________________
>> tcpm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tcpm
>>
>>
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm
>