Packet number echo with fixed-length, 32-bit packet and echo numbers #393
Conversation
| and/or timestamps. | ||
|
|
||
| The Packet Number Echo field SHOULD be present on 1-RTT packets containing at | ||
| least one ACK frame (see {{frame-ack}}). For efficiency's sake, it MAY be |
There was a problem hiding this comment.
Is there any reason hat the Echo should be in packets containing ACK frames? Since the Echo is only used by middleboxes, for whom the payload is opaque anyway, it shouldn't matter which packet the Echo is sent on.
Even though it doesn't reveal a lot about the packet contents, I'd prefer to not divulge any information about the frame types contained in a packet, unless there's a compelling reason to do so.
| The Packet Number Echo field SHOULD be present on 1-RTT packets containing at | ||
| least one ACK frame (see {{frame-ack}}). For efficiency's sake, it MAY be | ||
| omitted if a 1-RTT packet containing an ACK frame has already been sent during a | ||
| time interval equal to the sender's current estimate of the RTT. |
There was a problem hiding this comment.
This is actually a big difference. When a peer is sending stream data, the receiver will generate an ACK for every two packets received. On high bandwidth links, this means that a lot of ACKs are sent per RTT.
I think we should be explicit about this and just require one Echo per RTT.
There was a problem hiding this comment.
or alternatively, you could remove the largest_acked out of the ACK frame and require this on all packets that carry an ACK frame.
| wire, only the least significant 32 bits of the packet number are transmitted | ||
| over the wire. The actual packet number for each packet is reconstructed at the | ||
| receiver based on the largest packet number received on a successfully | ||
| authenticated packet. |
There was a problem hiding this comment.
Is there any reason for a receiver to reconstruct the echoed packet number? If I understand this PR correctly, this value is of no interest for the end points, but only for middleboxes.
There was a problem hiding this comment.
My bad. As Brian pointed out, this change refers to the actual packet number. I assumed it referred to the Echo, since there were changes in this PR (which probably need a separate issue then, don't they?).
|
On 13 Mar 2017, at 15:25, Marten Seemann ***@***.***> wrote:
@marten-seemann commented on this pull request.
In draft-ietf-quic-transport.md:
>
### Initial Packet Number
The initial value for packet number MUST be a 31-bit random number. That is,
the value is selected from an uniform random distribution between 0 and 2^31-1.
{{?RFC4086}} provides guidance on the generation of random values.
-The first set of packets sent by an endpoint MUST include the low 32-bits of the
-packet number. Once any packet has been acknowledged, subsequent packets can
-use a shorter packet number encoding.
+
+### Packet Number Echo {#packet-number-echo}
+
+If present, the Packet Number Echo field contains the least significant 32 bits
+of the highest packet number seen in the opposite direction before this packet
+was sent. This allows devices along the path to estimate round-trip times and
+observe indications of loss, for passive performance measurement of QUIC flows
+equivalent to present techniques using TCP sequence and acknowledgement numbers
+and/or timestamps.
+
+The Packet Number Echo field SHOULD be present on 1-RTT packets containing at
+least one ACK frame (see {{frame-ack}}). For efficiency's sake, it MAY be
Is there any reason hat the Echo should be in packets containing ACK frames? Since the Echo is only used by middleboxes, for whom the payload is opaque anyway, it shouldn't matter which packet the Echo is sent on.
Even though it doesn't reveal a lot about the packet contents, I'd prefer to not divulge any information about the frame types contained in a packet, unless there's a compelling reason to do so.
The intention here was to make it easy to determine when to place an echo on any given packet. Since the echo enhances the information available in a TCP ACK, a QUIC ACK seemed the most analogous place to do this. You're right, though; there's no reason for anything on path to know that a given packet contains ACK frames or not. So "at least once per RTT" is sufficient.
… —
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
On 13 Mar 2017, at 15:32, Marten Seemann ***@***.***> wrote:
@marten-seemann commented on this pull request.
In draft-ietf-quic-transport.md:
> @@ -676,42 +682,38 @@ CONNECTION_CLOSE frame with the error code QUIC_SEQUENCE_NUMBER_LIMIT_REACHED
(connection termination is described in {{termination}}.)
To reduce the number of bits required to represent the packet number over the
-wire, only the least significant bits of the packet number are transmitted over
-the wire, up to 48 bits. The actual packet number for each packet is
-reconstructed at the receiver based on the largest packet number received on a
-successfully authenticated packet.
+wire, only the least significant 32 bits of the packet number are transmitted
+over the wire. The actual packet number for each packet is reconstructed at the
+receiver based on the largest packet number received on a successfully
+authenticated packet.
Is there any reason for a receiver to reconstruct the echoed packet number? If I understand this PR correctly, this value is of no interest for the end points, but only for middleboxes.
This text refers to the packet number, not the echo.
… You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
janaiyengar
added
the
needs-discussion
|
thinking about it a bit more, I think the "do we want variable length packet numbers?" discussion is completely orthogonal to the "do we want packet number echo?" discussion, so let's talk about this in #391 for now... |
Version of #391 (replacing #368), adds optional packet number echo to the short header, but makes both packet number and packet number echo fields in the short header 32 bits. Implemented largely by removing complexity from #391.