Subject: Re: [quicwg/base-drafts] Remove ack_delay_exponent TP (#2670)

From: Martin Thomson <[email-masked]>
Date: Tue, 11 Jun 2019 23:26:43 -0700

So I'm seeing a few concerns highlighted here:

1. Some people would like to keep the delay encoding small (Ian); others don't care if it is bigger (Christian).
2. Native time is often in milliseconds.  Having to encoding microseconds with an exponent gets close (2^10 =~ 10^3), but it's not great (Kazuho).

The strength of feeling isn't strong, but my impression is that we have three options.

a. Use an exponent (leave as-is).
b. Move to multiplication instead of exponentiation.
c. Drop any scaling factor and encode the value directly.

As I mentioned before, there seems to be slightly more interest in option b, but it's not a strong one.

Of those who don't seem to like option b, Christian seems to prefer c and a over b and Ian seems happy with a.

Is that a fair assessment?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2670#issuecomment-501138176

---

From: Nick Banks <[email-masked]>
Date: Wed, 12 Jun 2019 06:47:46 -0700

I'm in the same boat as Christian. If we're willing to make a change, drop the scaling factor; otherwise just leave things as they are.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2670#issuecomment-501281023

---

From: ianswett <[email-masked]>
Date: Wed, 12 Jun 2019 06:51:28 -0700

@martinthomson I believe that's an accurate assessment.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2670#issuecomment-501282560

---

From: Marten Seemann <[email-masked]>
Date: Wed, 12 Jun 2019 07:09:26 -0700

Considering that we can easily use a varint to encode every multiplier value we want, an exponent seems to be strictly worse than a multiplier.
The only reason to keep the exponent would be our laziness to update our implementations. In my opinion, this is a small price to pay for future flexibility (and to get rid of the rounding issues that @kazuho described).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2670#issuecomment-501290708

---

From: MikkelFJ <[email-masked]>
Date: Wed, 12 Jun 2019 07:43:20 -0700

These rounding issues make no sense to me, as I have argued in the above. On the contrary division becomes cheaper with exponents when you have to compute the actual timer interval. But even with a multiplier, the sender controls the factor and can therefore divide by a constant, so a multiplier is not fatal compared to an exponent. I just don't see a great benefit.

I'm inclined to think that we could do without a multiplier or exponent altogether if we have microsecond units always.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2670#issuecomment-501305634

---

From: Christian Huitema <[email-masked]>
Date: Wed, 12 Jun 2019 08:19:36 -0700

The whole thing looks like a storm in a cup of tea. I don't buy the implementation issues. On a modern computer, computing "x = (internal-value*unit)" has exactly the same cost as "x =  (internal-value*unit)>>exponent". There is no branching involved, the instructions are pipe-lined, the next pipeline stall will come during the encoding to varint in all cases.

My preference if we do change things is to have a straight microsecond count, no scaling involved. But I get Ian's point that this makes the varint encoding slightly longer, which causes some overhead. That would be an argument for just keeping the spec as is.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2670#issuecomment-501322145

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 12 Jun 2019 19:15:17 -0700

Unsurprisingly, I prefer _b_ (multiplication), and the reason is as follows.

As @huitema points out, the computational cost of using a multiplier is no worse than using an exponent, and I second @marten-seemann's comment that use of exponent is strictly worse than using a multiplier. I do not think there is a justifiable reason to choose _a_ (exponent).

The network overhead of using no scaling factor would be 2 to 3 bytes per packet that contains an ACK, for the primary use-case of QUIC v1 traffic. This is because we can assume that connections between web browsers and servers would be in most cases greater than 16.383 milliseconds.

Considering the effort we have spent in reducing the number of bytes being transmitted on the wire, I think it might make more sense to have a multiplier than removing the scaling factor.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2670#issuecomment-501521948

---

From: MikkelFJ <[email-masked]>
Date: Wed, 12 Jun 2019 23:12:32 -0700

Maybe it is worth saving those bytes. But another argument not prominent in the discussion is the risk of getting the scale wrong since it applies to all paths and might be hardcoded in implementations that do not adapt to different networking environments. This is why I think the fp16 approach is better (with overhead slightly above a multiplication), but I can see why people dislike a non-standard algorithm.

Therefore the question is really if the bytes saved are worth the problems a bad scale might induce.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2670#issuecomment-501563239