ACK delay & RTT estimation

[pietdevaere]

Adding RTT estimation to the congestion controller.

I added both QUIC and TCP-style estimates. The TCP style estimates do not consider the ACK Delay field. They might be useful later to see what the influence is of moving the stamping of the ACK Delay and the recording of the Rx time of packets.

For this I had to populate the ACK Delay field in ACK frames. I currently use the IEEE 754 binary16 half precision format to encode the time. This is not exactly the format from draft-ietf-quic-transport-07, but as that format is under review, implementing it seems a waste of time. I borrowed the code for this from https://github.com/h2so5/half, which is CC0.

[ekr]

How different is this from the existing format? I.e., is it going to produce crazy results when interpreted by other stacks?

[pietdevaere]

As per -07

The bit format is loosely modeled after IEEE 754

I didn't look at it in detail, but I think the main difference is that it is an unsigned float instead of a signed one.

Considering the crazy results: draft-ietf-quic-recovery specifies a sanity check to make sure that ACK delay > RTT, so if this value is wrong, the worst that can (should?) happen is that the endpoint assumes that the link RTT is 0.

In -08 the format will change completely.

[ekr]

This looks basically sound, but given that we are now at -08, can you update the float format?

[pietdevaere]

The new format is a varint. Perhaps we should park this PR until varint support is added?

[ekr]

Sure. I'll be adding varint support in the next week or so.

…

On Fri, Dec 22, 2017 at 1:47 AM, Piet De Vaere ***@***.***> wrote: The new format is a varint. Perhaps we should park this PR until varint support is added? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#40 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABD1oTJr830ZNilUpV48j_zMcnqJJK_aks5tC3qYgaJpZM4Qzq3i> .