Re: [tcpm] TCP Tuning for HTTP - update

[SALLANTIN Renaud <[e-mail]>]

Hi all, 

IMO, such a document could be very useful, 
But it can also be dangerous.

For instance, the following statement seems to shut the door on other solutions than IW10. Unfortunately, if IW10 improved TCP startup efficiency, it remains not efficient in case of large RTT networks (such as satellite systems for instance).

   There has been experimentation with larger initial windows in
   combination with packet pacing, however IW10 has been reported to
   perform fairly well even in both general and high volume use cases. 

IMO, this doc must describe the best current practices, but also emphasize the remaining issues.

BR, 
Renaud



-----Message d'origine-----
De : tcpm [mailto:[e-mail]] De la part de Kuhn Nicolas
Envoyé : vendredi 19 août 2016 10:14
À : [e-mail]; Yuchung Cheng
Cc : Mark Nottingham; [e-mail]; Patrick McManus; Daniel Stenberg
Objet : Re: [tcpm] TCP Tuning for HTTP - update

Hi all, 

I agree with the recommendation on enabling pacing.
If flows are multiplexed such as in HTTP2, losses at slow start can be very damaging. 
I have proposed some text inline. 

Cheers,

Nico

-----Message d'origine-----
De : tcpm [mailto:[e-mail]] De la part de Gorry Fairhurst Envoyé : vendredi 19 août 2016 09:48 À : Yuchung Cheng Cc : [e-mail]; Mark Nottingham; Patrick McManus; Daniel Stenberg Objet : Re: [tcpm] TCP Tuning for HTTP - update

On 18/08/2016 18:34, Yuchung Cheng wrote:
>
>
> On Thu, Aug 18, 2016 at 9:54 AM, Gorry Fairhurst <[e-mail] 
> <mailto:[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.
>
I agree
> 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.
>
+1

==============
[NK]
Regarding the point on enabling pacing, I would suggest text changes for the section "3.2.  Initial Window".

From
"
   There has been experimentation with larger initial windows in
   combination with packet pacing, however IW10 has been reported to
   perform fairly well even in both general and high volume use cases.
"

To
"
  IW10 has been reported to
  perform fairly well even in both general and high volume use cases. 
  There has been experimentation with larger initial windows in
  combination with packet pacing. Packet pacing at slow start
  reduces congestion losses at the beginning of the connection.
  Moreover, losses at the beginning of the connection result in retransmission
  delay and an early slow start exit. In this case, degraded performances when flows are 
  multiplexed such as in HTTP2 can be expected.   
  Packet pacing at slow start also provides clear benefits for challenged networks,
  such as capacity-limited or long-RTT networks. 
"
Then, there could be text mentioning that "enabling packet pacing is recommended".
Or something similar. 
==============

> 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.
>
Worth metioning.
> 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]
>         <mailto:[e-mail]>] On Behalf Of Mark Nottingham
>         Sent: Wednesday, August 17, 2016 4:03 AM
>         To: [e-mail] <mailto:[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
>         <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/
>         <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] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/tcpm
>         <https://www.ietf.org/mailman/listinfo/tcpm>
>
>         _______________________________________________
>         tcpm mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/tcpm
>         <https://www.ietf.org/mailman/listinfo/tcpm>
>
>
>     _______________________________________________
>     tcpm mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/tcpm
>     <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