Doubt in TCP-BBR, Pacing and RTO

[Vivek Jain]

Hi All,

According to RFC 6298 clause 2.4, on receiving a "New" ack, we restart retransmission timer. But if pacing timer is higher than RTO, and socket is not sending any packet due to pacing timer, Retransmission Timeout will occur. I wonder if there is any possibility that the network congestion leads to a very low pacing rate, such that after each packet, there is a Timeout? If this is possible, how is BBR currently handling this?

Best,

Vivek Jain

[Jonathan Morton]

RTO shpuld always be greater than RTT.  Therefore, the last ack to arrive before a timeout will normally show that all transmitted data has arrived at the receiver.  In that case, no retransmission will occur.

- Jonathan Morton

[Neal Cardwell]

To expand on Jonathan's nice answer, the RTO generally adapts itself to the delay structure of the traffic (whether delays are due to the network or to pacing), so that in steady-state the RTO is almost always higher than the RTT. So even if there is a brief delay increase that causes a spurious RTO, the RTO will quickly adapt until it is longer than the RTT again.

In practice, it should be rare for BBR pacing to cause an RTO. The BBR pacing delay adjusts to adapt to the network rate. So for the BBR pacing rate to be set low enough for this to be an issue, this means the network was already delivering packets very slowly, so the RTO should have adapted itself to the network-induced delays before the BBR pacing delays become the limiting factor.

neal

On Tue, Nov 28, 2017 at 12:12 PM, Jonathan Morton <chrom...@gmail.com> wrote:

RTO shpuld always be greater than RTT.  Therefore, the last ack to arrive before a timeout will normally show that all transmitted data has arrived at the receiver.  In that case, no retransmission will occur.

- Jonathan Morton

--
You received this message because you are subscribed to the Google Groups "BBR Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bbr-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Vivek Jain]

Thanks Neal and Jonathan for the reply.

Yes, I agree that RTO will get adjusted according to RTT. But I think RTT will include pacing time only when pacing from traffic control layer is used because that's when the packet has left transport layer and timer for the RTT calculation starts. Whereas, if pacing is used at the transport layer, this timer won't start until the packet has been transmitted from this layer.

Please let me know if I am thinking in the right direction.

Best,

Vivek Jain

[Neal Cardwell]

On Thu, Nov 30, 2017 at 1:36 PM, Vivek Jain <jain.viv...@gmail.com> wrote:

Thanks Neal and Jonathan for the reply.

Yes, I agree that RTO will get adjusted according to RTT. But I think RTT will include pacing time only when pacing from traffic control layer is used because that's when the packet has left transport layer and timer for the RTT calculation starts. Whereas, if pacing is used at the transport layer, this timer won't start until the packet has been transmitted from this layer.

But if the pacing is done at the TCP layer, then there is no pacing delay between the TCP transmit processing and the TCP ACK processing, so the RTT measurement and RTO should not need to include a budget for pacing delays.

If the pacing is done at the TCP layer then the behavior of RTT samples and RTOs should be equivalent to an application that just happens to write data at the rate at which the CC would like to pace the data; in either case there is some scheduling decision independent of and outside of the transmit, ACK, RTT, and RTO processing. And we already know that the TCP RTT and RTO algorithms are pretty robust to arbitrary application write patterns. So AFAICT there should be no problem. :-)

Please let us know you construct a particular case (e.g. packetdrill) where you see a problem.

Thanks!

neal