Packet pacing in Quic

[Fatima Zarinni]

Hi All,

I was wondering if the packet pacing congestion control scheme is fully implemented in the Quic toy server and chrome browser ? If yes, then is there a way to enable this feature ?

Thank you,

Fatima

[Ryan Hamilton]

Yes, it is enabled by default now.

Cheers,

Ryan

--
You received this message because you are subscribed to the Google Groups "QUIC Prototype Protocol Discussion group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to proto-quic+...@chromium.org.
To post to this group, send email to proto...@chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.

[Fatima Zarinni]

Hi Ryan,

Thank you for the quick response.

So, I am thinking that this means that the TCP cubic-like scheme is no longer the default congestion control scheme. To enable TCP-cubic all we have to do is disable the packet pacing scheme at the client.

May I please know if I am on the right track ? I would like to run experiments for both types of congestion control schemes.

Thank you,

Fatima 

[Ian Swett]

QUIC by default uses TCP-Cubic with packet pacing.  There is a PacingRate() method(link) which allows TCP cubic to indicate the pacing rate.  We were using the PACE connection option to enable it, but now it's useless and should be removed, so I'll clean that up.

You can compare QUIC's Cubic implementation with it's Reno implementation by supplying the RENO congestion option in the handshake.  

For a full list of connection options we support currently, see: 

 https://code.google.com/p/chromium/codesearch#chromium/src/net/quic/crypto/crypto_protocol.h&sq=package:chromium&type=cs&l=55

[Fatima Zarinni]

Thank you! It is clearer now. 

Best regards,

Fatima

[刘婷]

Do you know how to change congestion control in quic?Thank you!

在 2015年5月12日星期二 UTC+8下午11:56:08，Ian Swett写道：

[Ryan Hamilton]

As Ian mentioned, you would need to supply RENO in the connection options of the CHLO.

[Bruno Gomes Correia Rodrigues]

I wish to disable the QUIC pacing.

Do you know if I put the delay to 0 in "net/quic/congestion_control/pacing_sender.cc", in this line "QuicTime::Delta delay = PacingRate().TransferTime(bytes);" I'll disable the pacing but still using the TCP CUBIC congestion control?

[Ian Swett]

The easiest way is to remove line 147 in QuicSentPacketManager::SetFromConfig where pacing is enabled: https://code.google.com/p/chromium/codesearch#chromium/src/net/quic/quic_sent_packet_manager.cc&sq=package:chromium&l=147&rcl=1440948402

[Wesley Davison]

As I can not modify the server side, is there some flag that the client could send to the server for not using pacing as rate control?

Thanks in advance,

Wesley

[Ian Swett]

A while after we found pacing reduced packet loss, improved tail latency, and had no negative effects, we removed the ability to disable pacing in our code.  If you have a compelling use case, it's possible to restore it, but I am not aware of any at this point.

[Wesley Davison]

I am still investigating this issue, but my preliminary researches/results indicate that the average throughput when downloading small objects, in a start-and-stop scenario, is degraded by pacing. To support my results, the authors in [1] evaluated the TCP with pacing for HTTP Adaptive Streaming (my scenario, too). In summary, the authors show that pacing can degrade significantly the TCP performance. As QUIC implements by default the pacing scheme, as well as the CUBIC algorithm, I think the results are still valid for QUIC, too.

As the QUIC server available for community is different from the one implemented at Google servers, and I am planning to use real QUIC servers,  I can not turn off the pacing scheme at server side.

Based on this, do you consider that is possible to restore the flag?

[1] J. Esteban, S. A. Benno, A. Beck, Y. Guo, V. Hilt, and I. Rimac, “Interactions between HTTP adaptive streaming and TCP,” in Proceedings of the 22nd international workshop on Network and Operating System Support for Digital Audio and Video - NOSSDAV ’12, 2012, p. 21.

[Ian Swett]

In http://london.csl.toronto.edu/nossdav12/slides/s1_3.pdf, you mention an application space pacing implementation.  Can you detail the approach you used?  Particularly, how you calculated the rate during slow start and congestion avoidance, as well as the initial burst, and pacing granularity(if any)?

I'll bring it up at this week's QUIC team meeting to gauge interest in creating a connection option to disable pacing.

[Wesley Davison]

I guess my previous email was not very clear, but I have no relation with the researchers of the paper. What I want to say was that my experiments with QUIC and Pacing have a similar behavior than the experiments published by Esteban et. al, in 2012. Due that, unfortunately I can not answer your question about the pacing implementation. However, I can try to contact the authors to get this answer.

Thanks in advance,

Wesley

[Wesley Davison]

Hi,

is there any update about the implementation of a pacing flag?

Thanks in advance, 

Wesley

[Wesley Davison]

Any news?

[Ian Swett]

The team discussed it and we've decided against adding one for now, since we think pacing is a valuable feature for all congestion control approaches, as well as being good for infrastucture(ie: ToR switches, etc).  

That being said, if we decide to add one in the future, we'll let you know.

[Ingemar Johansson]

Hi

It would be good to see what the negative effects of packet pacing are, based on papers that I read the benefits seem to outweight the drawbacks. Based on personal experience (LTE simulations) my current conclusion is that pacing is very helpful in breaking up ACK compression, something that can otherwise easily happen with LTE access due to possible retransmissions on the MAC layer.

/Ingemar

[Jim Roskind]

The only drawback of pacing that I recall from the initial tests was that pacing delays sending packets... and hence there is a chance that it will increase latency (of a delayed packet at the tail end of a paced group).  The results I presented at IETF 88 showed (as I recall) that the pacing had a significant impact on reducing packet loss.  So you are trading a risk of sending later... vs sending sooner, but having the packet dropped. <oops>.  The conjecture of course was that a "burst" or "rapid train" of packets had a much better chance of instigating a buffer-overrun (and a packet loss) upon entry into a router that was operating close to its bloated limits.

When combined with FEC (with single-lost-packet recovery), the  benefits seemed (at the time I was doing experiments) to be quite significant.  Again, the results should be on slides in the IETF 88 presentation on QUIC.  Take a look at the graphs on the last few pages.

I think I also saw some interesting (negative) results for pacing too slowly.  As I recall, if you sent packets close(r) together, they might (at some networking layer) be coalesced, and conveyed together.  As a result, you'd typically then get all (both?) of them, or none of them.  In contrast, if you paced things out, then you might suffer independent packet loss of one or the other.  IF you system (receiver) needed both packets, then you'd rather go with the all-or-nothing plan (pace them closer together!).  The analogy would be that if you were ordering skis, poles, and boots for a ski trip (this Saturday) from Amazon, you'd *much* rather have all items shipped in one box, assuming each box has a fixed loss probability.  With separate boxes, there is a much higher chance that one of the boxes won't make it (right away), and you really want "all or nothing by Saturday."

YMMV... and this is all from distant memories.

Jim