jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-quic-load-balancers

Commentary: Carefully phrased language that considers 's suggestion that SCID may not be stable across versions , and tries to suggest ( IP , port , DCID ) as a suitable long header hash without making promises on behalf of quic - invariants . 
 sayeth on the list : It would be useful to include something like this in Section 4 as a non - normative hint on what fields to use , since our hint currently consists of an example that just uses the DCID . Similarly , make that assumption clearer in Section 8 . 
 For what it 's worth , Google 's load balancer only uses destination CIDs for routing . We always pick 64bit CIDs during the handshake so we can assume that short headers always carry 64bit CIDs . 
 Do all CIDs resolve to a valid server ID ? 
 do you not care about an attacker specifically crafting destination CIDs to attack a particular server ? 
 We do not have a concept of server ID , but yes every CID routes to a server . We do not care about that attack . I have n't seen any indication that it can actually cause harm in real life . 
 very well , then you have no non - compliant DCIDs . You would only need to upgrade your LBs for new versions if they allowed client - chosen DCIDs < 8 bytes .
on the time scale of a QUIC connection handshake.
on the time scale of a QUIC connection handshake.  See also version-
invariance.
In this interval, some exposed fields (e.g.  UDP address and port,
source and client-generated destination Connection ID) remain
constant for all packets in the connection.  For example, 0RTT and
Initial packets use the same CIDs and ports.
While the client is using DCIDs it generated, some exposed fields
(IP address, UDP port, client-generated destination Connection ID)
remain constant for all packets sent on the same connection.
While this document does not update the commitments in QUIC-
INVARIANTS, the additional assumptions are minimal and narrowly
scoped, and provide a likely set of constants that load balancers can
use with minimal risk of version- dependence.
Draft: draft-ietf-quic-load-balancers

Commentary: Somewhat obliquely , this addresses . 
 LGTM
Load balancers MUST forward packets with long headers with non-
compliant DCIDs to an active server using an algorithm of its own
choosing.  It need not coordinate this algorithm with the servers.
The algorithm SHOULD be deterministic over short time scales so that
related packets go to the same server.  For example, a non-compliant
DCID might be converted to an integer and divided by the number of
servers, with the modulus used to forward the packet.  The number of
servers is usually consistent on the time scale of a QUIC connection
handshake.
Load balancers MUST forward packets with long headers with non-
compliant DCIDs to an active server using an algorithm of its own
choosing.  It need not coordinate this algorithm with the servers.
The algorithm SHOULD be deterministic over short time scales so that
related packets go to the same server.  The design of this algorithm
SHOULD consider the version-invariant properties of QUIC described in
QUIC-INVARIANTS to maximize its robustness to future versions of
QUIC.  For example, a non-compliant DCID might be converted to an
integer and divided by the number of servers, with the modulus used
to forward the packet.  The number of servers is usually consistent
on the time scale of a QUIC connection handshake.
Retry Services are inherently dependent on the format (and existence)
of Retry Packets in each version of QUIC, and so Retry Service
configuration explicitly includes the supported QUIC versions.
The server ID encodings, and requirements for their handling, are
designed to be QUIC version independent (see QUIC-INVARIANTS).  A
QUIC-LB load balancer will generally not require changes as servers
deploy new versions of QUIC.  However, there are several unlikely
future design decisions that could impact the operation of QUIC-LB.
The maximum Connection ID length could be below the minimum necessary
for one or more encoding algorithms.
Incoming short headers do not contain DCIDs that are client-
generated.
The use of client-generated incoming DCIDs does not persist beyond
a few round trips in the connection.
In this interval, some exposed fields (e.g.  UDP address and port,
source and client-generated destination Connection ID) remain
constant for all packets in the connection.  For example, 0RTT and
Initial packets use the same CIDs and ports.
If these assumptions are invalid, this specification is likely to
lead to loss of packets that contain non-compliant DCIDs, and in
extreme cases connection failure.
Draft: draft-ietf-quic-load-balancers

Commentary: this is mostly to test I 've fixed some integration issues .
The following pseudocode depicts the data items necessary to store a
full QUIC-LB configuration at the server.  It is meant to describe
the conceptual range and not specify the presentation of such
configuration in an internet packet.  The comments signify the range
of acceptable values where applicable.
The following pseudocode describes the data items necessary to store
a full QUIC-LB configuration at the server.  It is meant to describe
the conceptual range and not specify the presentation of such
configuration in an internet packet.  The comments signify the range
of acceptable values where applicable.
Draft: draft-ietf-quic-load-balancers

Commentary: Intended to 
 Some text on how a server cluster might support moving of connections from one server instance to another would be useful . The current design might permit portability under certain conditions , but there are things that might need to be considered , such as the way in stateless resets are generated . 
 Are you referring to load balancing already existing connections to a new server ? Are you envisioning the first server issuing new CIDs ( that point to the new server ) and setting   To to retire the old CIDs so that future traffic redirect to the new server ? How do you imagine the rest of the connection state would get moved ? 
 This applies to cases where clusters are rebalanced , where instances go down and others are expected to pick up the slack , and all similar cases . In some cases this requires an unspecified mechanism for transferring state between instances . In others , the instance might remain constant but the identifiers used might need to rotate . This is likely addressed by using Retire Prior To as you say . Text on that would help . 
 Good idea , it would n't hurt to have a short non - normative section on this . 
 Seems fine .
This section discusses considerations for some deployment scenarios
not implied by the specification above.
Some deployments may transparently move a connection from one server
to another.  The means of transferring connection state between
servers is out of scope of this document.
To support a handover, a server involved in the transition could
issue CIDs that map to the new server via a NEW_CONNECTION_ID frame,
and retire CIDs associated with the new server using the "Retire
Prior To" field in that frame.
Alternately, if the old server is going offline, the load balancer
could simply map its server ID to the new server's address.
Draft: draft-ietf-quic-load-balancers

Commentary: resolves ( also the changelog for this draft version )
While it is possible to construct a scheme that supports multiple
low-state load balancers in the path, by using different parts of the
connection ID to encode routing information for each load balancer,
this use case is out of scope for QUIC-LB.
Some network architectures may have multiple tiers of low-state load
balancers, where a first tier of devices makes a routing decision to
the next tier, and so on until packets reach the server.  Although
QUIC-LB is not explicitly designed for this use case, it is possible
to support it.
If each load balancer is assigned a range of server IDs that is a
subset of the range of IDs assigned to devices that are closer to the
client, then the first devices to process an incoming packet can
extract the server ID and then map it to the correct forwrading
address.  Note that this solution is extensible to arbitrarily large
numbers of load-balancing tiers, as the maximum server ID space is
quite large.