Re: [quicwg/base-drafts] Change Packet Number Gap to Packet Number Offset (#1307)

[Mike Bishop <[e-mail]>]

MikeBishop requested changes on this pull request.

I think @marten-seemann is correct -- this solution only makes sense as a transform on every packet, not just as something to do on particular packets with a new CID.  That's my key feedback on fixing the PR.

On the proposal itself, however, I share @huitema's concerns that correlation of gaps between flows is still possible.  A future PR for a shuffle can make that harder for an observer, but only so much (observing over the shuffle window, you can perform the same analysis).

> @@ -832,6 +832,27 @@ Use of a secure random number generator {{?RFC4086}} is not necessary for
 generating the initial packet number, nor is it necessary that the value be
 uniformly distributed.
 
+### New Connection ID Packet Numbers
+
+Packets with with new connection IDs have special rules for encoding the packet
+number in the headers.  They use an offset (see {{packet-number-offset}}) to
+transform the packet number via the following:

The gap in the actual packet number was introduced at the point you sent the first packet with a new CID.  This proposal is a transformation of the actual packet number for wire presentation, so it needs to occur every time.

> @@ -832,6 +832,27 @@ Use of a secure random number generator {{?RFC4086}} is not necessary for
 generating the initial packet number, nor is it necessary that the value be
 uniformly distributed.
 
+### New Connection ID Packet Numbers
+
+Packets with with new connection IDs have special rules for encoding the packet
+number in the headers.  They use an offset (see {{packet-number-offset}}) to
+transform the packet number via the following:
+
+~~~
+transformed_packet_number = (packet_number + offset) % 2^62

This might actually be okay, but the possibility that the transformed packet number might wrap around to zero before being truncated feels a little odd.

> @@ -832,6 +832,27 @@ Use of a secure random number generator {{?RFC4086}} is not necessary for
 generating the initial packet number, nor is it necessary that the value be
 uniformly distributed.
 
+### New Connection ID Packet Numbers
+
+Packets with with new connection IDs have special rules for encoding the packet
+number in the headers.  They use an offset (see {{packet-number-offset}}) to
+transform the packet number via the following:
+
+~~~
+transformed_packet_number = (packet_number + offset) % 2^62
+~~~
+
+Once transformed, the normal rules of packet number encoding are followed, only
+encoding the least number of bits required.

"only" and "the least" feels duplicative.  Maybe just replace the part with the comma with a reference to the section where the truncation is defined?

Better yet, since this is effectively a transform on every packet number, put this in the section about truncation (it becomes a description of how the 64-bit number is encoded on the wire) and make this section purely about determining what the offset will be.

-- 
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/pull/1307#pullrequestreview-114065522