Skip to content

Commit

Permalink
Script updating gh-pages from c732b46. [ci skip]
Browse files Browse the repository at this point in the history
  • Loading branch information
ID Bot committed Oct 19, 2023
1 parent b690f76 commit 0bf2746
Show file tree
Hide file tree
Showing 2 changed files with 27 additions and 27 deletions.
26 changes: 13 additions & 13 deletions marten-editorial-pass/draft-ietf-quic-reliable-stream-reset.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -10,7 +10,7 @@
<meta content="
QUIC defines a RESET_STREAM frame to abort sending on a stream. When a sender
resets a stream, it also stops retransmitting STREAM frames for this stream in
the of packet loss. On the receiver side, there is no guarantee that any data
the of packet loss. On the receiving side, there is no guarantee that any data
sent on that stream is delivered.
This document defines a new QUIC frame, the RESET_STREAM_AT frame, that allows
resetting a stream, while guaranteeing reliable delivery of stream data up to a
Expand Down Expand Up @@ -1074,7 +1074,7 @@ <h1 id="title">Reliable QUIC Stream Resets</h1>
<h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">QUIC defines a RESET_STREAM frame to abort sending on a stream. When a sender
resets a stream, it also stops retransmitting STREAM frames for this stream in
the of packet loss. On the receiver side, there is no guarantee that any data
the of packet loss. On the receiving side, there is no guarantee that any data
sent on that stream is delivered.<a href="#section-abstract-1" class="pilcrow"></a></p>
<p id="section-abstract-2">This document defines a new QUIC frame, the RESET_STREAM_AT frame, that allows
resetting a stream, while guaranteeing reliable delivery of stream data up to a
Expand Down Expand Up @@ -1204,8 +1204,8 @@ <h2 id="name-introduction">
</h2>
<p id="section-1-1">QUIC version 1 (<span>[<a href="#RFC9000" class="cite xref">RFC9000</a>]</span>) allows streams to be reset. When a stream is
reset, the sender doesn't retransmit stream data for the respective stream. On
the receiver side, the QUIC stack is free to surface the stream reset to the
application immediately, even if it has already received more stream data for
the receiving side, the QUIC stack is free to surface the stream reset to the
application immediately, without providing any stream data it has received for
that stream.<a href="#section-1-1" class="pilcrow"></a></p>
<p id="section-1-2">Some applications running on top of QUIC send an identifier at the beginning of
the stream in order to associate that stream with a specific subcomponent of the
Expand All @@ -1221,7 +1221,7 @@ <h2 id="name-introduction">
guaranteeing that all data received from the source is delivered to the peer.<a href="#section-1-3" class="pilcrow"></a></p>
<p id="section-1-4">This document describes a QUIC extension defining a new frame type, the
RESET_STREAM_AT frame. This frame allows an endpoint to mark a portion at the
beginning of the stream which will then be guaranteed to be delivered reliably,
beginning of the stream which will then be guaranteed to be reliably delivered,
even if the stream was reset.<a href="#section-1-4" class="pilcrow"></a></p>
</section>
</div>
Expand Down Expand Up @@ -1311,8 +1311,8 @@ <h2 id="name-resetting-streams">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-resetting-streams" class="section-name selfRef">Resetting Streams</a>
</h2>
<p id="section-5-1">A sender that wants to reset a stream but also deliver some bytes to the
receiver, the sender sends a RESET_STREAM_AT frame with the Reliable Size field
specifying the amount of data to be delivered.<a href="#section-5-1" class="pilcrow"></a></p>
receiver sends a RESET_STREAM_AT frame with the Reliable Size field specifying
the amount of data to be delivered.<a href="#section-5-1" class="pilcrow"></a></p>
<p id="section-5-2">When resetting a stream without the intent to deliver any data to the receiver,
the sender uses a RESET_STREAM frame (<span><a href="https://rfc-editor.org/rfc/rfc9000#section-3.2" class="relref">Section 3.2</a> of [<a href="#RFC9000" class="cite xref">RFC9000</a>]</span>). The sender
<span class="bcp14">MAY</span> also use a RESET_STREAM_AT frame with a Reliable Size of zero in place of a
Expand Down Expand Up @@ -1340,7 +1340,7 @@ <h3 id="name-multiple-reset_stream_at-re">
carrying the smallest Reliable Size as well as stream data up to that size,
until all acknowledgements for the stream data and the RESET_STREAM_AT frame are
received.<a href="#section-5.1-1" class="pilcrow"></a></p>
<p id="section-5.1-2">When sending multiple RESET_STREAM_AT and RESET_STREAM frames for the same
<p id="section-5.1-2">When sending multiple RESET_STREAM_AT or RESET_STREAM frames for the same
stream, the initiator <span class="bcp14">MUST NOT</span> increase the Reliable Size.<a href="#section-5.1-2" class="pilcrow"></a></p>
<p id="section-5.1-3">When receiving a RESET_STREAM_AT frame with a lower Reliable Size, the receiver
only needs to deliver data up the lower Reliable Size to the application. It
Expand All @@ -1364,7 +1364,7 @@ <h3 id="name-stream-states">
RESET_STREAM_AT frame is equivalent to that of the FIN bit. Both the
RESET_STREAM_AT frame and the FIN bit on a STREAM frame serve the same role:
signaling the amount of data to be delivered.<a href="#section-5.2-1" class="pilcrow"></a></p>
<p id="section-5.2-2">On the sender side, when the first RESET_STREAM_AT frame is sent, the sending
<p id="section-5.2-2">On the sending side, when the first RESET_STREAM_AT frame is sent, the sending
part of the stream enters the "Data Sent" state. Once the RESET_STREAM_AT frame
carrying the smallest Reliable Size and all stream data up to that byte offset
have been acknowledged, the sending part of the stream enters the "Data Recvd"
Expand All @@ -1373,11 +1373,11 @@ <h3 id="name-stream-states">
have already been sent and acknowledged. Conversely, the transition might take
multiple network roundtrips or require additional flow control credit issued by
the receiver.<a href="#section-5.2-2" class="pilcrow"></a></p>
<p id="section-5.2-3">On the receiver side, when a RESET_STREAM_AT frame is received, the receiving
<p id="section-5.2-3">On the receiving side, when a RESET_STREAM_AT frame is received, the receiving
part of the stream enters the "Size Known" state. Once all data up to the
smallest Reliable Size have been received, it enters the "Data Recvd" state.
Similarly to the server side, transition from "Size Known" to "Data Recvd" might
happen immediately or involve issuance of additional flow control credit.<a href="#section-5.2-3" class="pilcrow"></a></p>
Similarly to the sending side, transition from "Size Known" to "Data Recvd"
might happen immediately or involve issuance of additional flow control credit.<a href="#section-5.2-3" class="pilcrow"></a></p>
</section>
</div>
</section>
Expand All @@ -1391,7 +1391,7 @@ <h2 id="name-implementation-guidance">
FIN bit than to the RESET_STREAM frame (see <a href="#stream-states" class="auto internal xref">Section 5.2</a>). By sending a
RESET_STREAM_AT frame, the sender commits to delivering all bytes up to the
Reliable Size.<a href="#section-6-1" class="pilcrow"></a></p>
<p id="section-6-2">To the endpoints, the only differences from closing a stream by using the FIN
<p id="section-6-2">To the endpoints, the main differences from closing a stream by using the FIN
bit are:<a href="#section-6-2" class="pilcrow"></a></p>
<ul class="normal">
<li class="normal" id="section-6-3.1">
Expand Down
28 changes: 14 additions & 14 deletions marten-editorial-pass/draft-ietf-quic-reliable-stream-reset.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -16,7 +16,7 @@ Abstract

QUIC defines a RESET_STREAM frame to abort sending on a stream. When
a sender resets a stream, it also stops retransmitting STREAM frames
for this stream in the of packet loss. On the receiver side, there
for this stream in the of packet loss. On the receiving side, there
is no guarantee that any data sent on that stream is delivered.

This document defines a new QUIC frame, the RESET_STREAM_AT frame,
Expand Down Expand Up @@ -94,9 +94,9 @@ Table of Contents

QUIC version 1 ([RFC9000]) allows streams to be reset. When a stream
is reset, the sender doesn't retransmit stream data for the
respective stream. On the receiver side, the QUIC stack is free to
surface the stream reset to the application immediately, even if it
has already received more stream data for that stream.
respective stream. On the receiving side, the QUIC stack is free to
surface the stream reset to the application immediately, without
providing any stream data it has received for that stream.

Some applications running on top of QUIC send an identifier at the
beginning of the stream in order to associate that stream with a
Expand All @@ -117,7 +117,7 @@ Table of Contents
This document describes a QUIC extension defining a new frame type,
the RESET_STREAM_AT frame. This frame allows an endpoint to mark a
portion at the beginning of the stream which will then be guaranteed
to be delivered reliably, even if the stream was reset.
to be reliably delivered, even if the stream was reset.

2. Conventions and Definitions

Expand Down Expand Up @@ -184,8 +184,8 @@ Table of Contents
5. Resetting Streams

A sender that wants to reset a stream but also deliver some bytes to
the receiver, the sender sends a RESET_STREAM_AT frame with the
Reliable Size field specifying the amount of data to be delivered.
the receiver sends a RESET_STREAM_AT frame with the Reliable Size
field specifying the amount of data to be delivered.

When resetting a stream without the intent to deliver any data to the
receiver, the sender uses a RESET_STREAM frame (Section 3.2 of
Expand Down Expand Up @@ -219,7 +219,7 @@ Table of Contents
all acknowledgements for the stream data and the RESET_STREAM_AT
frame are received.

When sending multiple RESET_STREAM_AT and RESET_STREAM frames for the
When sending multiple RESET_STREAM_AT or RESET_STREAM frames for the
same stream, the initiator MUST NOT increase the Reliable Size.

When receiving a RESET_STREAM_AT frame with a lower Reliable Size,
Expand All @@ -246,9 +246,9 @@ Table of Contents
frame serve the same role: signaling the amount of data to be
delivered.

On the sender side, when the first RESET_STREAM_AT frame is sent, the
sending part of the stream enters the "Data Sent" state. Once the
RESET_STREAM_AT frame carrying the smallest Reliable Size and all
On the sending side, when the first RESET_STREAM_AT frame is sent,
the sending part of the stream enters the "Data Sent" state. Once
the RESET_STREAM_AT frame carrying the smallest Reliable Size and all
stream data up to that byte offset have been acknowledged, the
sending part of the stream enters the "Data Recvd" state. The
transition from "Data Sent" to "Data Recvd" happens immediately if
Expand All @@ -257,10 +257,10 @@ Table of Contents
the transition might take multiple network roundtrips or require
additional flow control credit issued by the receiver.

On the receiver side, when a RESET_STREAM_AT frame is received, the
On the receiving side, when a RESET_STREAM_AT frame is received, the
receiving part of the stream enters the "Size Known" state. Once all
data up to the smallest Reliable Size have been received, it enters
the "Data Recvd" state. Similarly to the server side, transition
the "Data Recvd" state. Similarly to the sending side, transition
from "Size Known" to "Data Recvd" might happen immediately or involve
issuance of additional flow control credit.

Expand All @@ -271,7 +271,7 @@ Table of Contents
By sending a RESET_STREAM_AT frame, the sender commits to delivering
all bytes up to the Reliable Size.

To the endpoints, the only differences from closing a stream by using
To the endpoints, the main differences from closing a stream by using
the FIN bit are:

* the offset up to which the sender commits to sending might be
Expand Down

0 comments on commit 0bf2746

Please sign in to comment.