From c9a52af640557511b4565bdb1546b58721a1cb27 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Tue, 9 Jun 2020 11:53:53 +1000 Subject: [PATCH 1/2] Remove "bundle" terminology We didn't really need to use a new "term" for the concept of including multiple frames in a packet. The use of "bundle" implied more than what was really happening. Using plain words is probably better. Closes #3736. --- draft-ietf-quic-transport.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 288782667a..24c2f85853 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -3336,9 +3336,9 @@ necessary as a connection error of type PROTOCOL_VIOLATION. A sender bundles one or more frames in a QUIC packet; see {{frames}}. -A sender can minimize per-packet bandwidth and computational costs by bundling -as many frames as possible within a QUIC packet. A sender MAY wait for a short -period of time to bundle multiple frames before sending a packet that is not +A sender can minimize per-packet bandwidth and computational costs by including +as many frames as possible in each QUIC packet. A sender MAY wait for a short +period of time to collect multiple frames before sending a packet that is not maximally packed, to avoid sending out large numbers of small packets. An implementation MAY use knowledge about application sending behavior or heuristics to determine whether and for how long to wait. This waiting period @@ -3354,8 +3354,8 @@ One of the benefits of QUIC is avoidance of head-of-line blocking across multiple streams. When a packet loss occurs, only streams with data in that packet are blocked waiting for a retransmission to be received, while other streams can continue making progress. Note that when data from multiple streams -is bundled into a single QUIC packet, loss of that packet blocks all those -streams from making progress. Implementations are advised to bundle as few +are included in a single QUIC packet, loss of that packet blocks all those +streams from making progress. Implementations are advised to include as few streams as necessary in outgoing packets without losing transmission efficiency to underfilled packets. From ad987657fce6c2375f10ad19d5ada3f031359dd3 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Tue, 9 Jun 2020 14:19:15 +1000 Subject: [PATCH 2/2] sdgfoihui --- draft-ietf-quic-transport.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 24c2f85853..d92d325ffa 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -3354,7 +3354,7 @@ One of the benefits of QUIC is avoidance of head-of-line blocking across multiple streams. When a packet loss occurs, only streams with data in that packet are blocked waiting for a retransmission to be received, while other streams can continue making progress. Note that when data from multiple streams -are included in a single QUIC packet, loss of that packet blocks all those +is included in a single QUIC packet, loss of that packet blocks all those streams from making progress. Implementations are advised to include as few streams as necessary in outgoing packets without losing transmission efficiency to underfilled packets.