jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-masque-connect-udp

Commentary: A proxy can receive a UDP packet from an origin to a client that can not fit within a DATAGRAM frame , given either the limit set by the maximum datagram frame size , or based on the current path MTU . In this case , one solution is for the proxy to generate ICMP errors back to the sender . If that sender implements PMTU discovery , it should adjust its size . 
 I think adding advice here is good , though we ca n't mandate sending ICMP because most OSes do n't let user space applications send ICMP . 
 Yes , we ca n't mandate it , but we should recommend it I think . For a full - blown production server , it should be possible . 
 Recommendation seems sensible . Although this does get me thinking about what the expectations of fragmentation are , we ca n't expect all UDP protocols to set DF . 
 The DATAGRAM capsule type offers one way to address this . Capsules can be arbitrarily large , because they 'll be reassembled by QUIC . If it wo n't fit in a QUIC DATAGRAM and you do n't want to drop it , it goes in a DATAGRAM capsule . Now , that might not always be desirable , because capsules do n't have all the behavior that causes you to choose datagrams in the first place ; a proxy that behaves that way will mess with PMTUD , and in the degenerate case cause the server to select an MTU back to the client that always gets encoded in capsules . Perhaps the client should be able to inform the server whether it prefers oversize messages to be tunneled or dropped ?
When using HTTP/3 with the QUIC Datagram extension DGRAM, UDP
payloads are transmitted in QUIC DATAGRAM frames.  Since those cannot
be fragmented, they can only carry payloads up to a given length
determined by the QUIC connection configuration and the path MTU.  If
a proxy is using QUIC DATAGRAM frames and it receives a UDP payload
from the target that will not fit inside a QUIC DATAGRAM frame, the
proxy SHOULD NOT send the UDP payload in a DATAGRAM capsule, as that
defeats the end-to-end unreliability characteristic that methods such
as Datagram Packetization Layer Path MTU Discovery (DPLPMTUD) depend
on RFC8899.  In this scenario, the proxy SHOULD drop the UDP payload
and send an ICMP "Packet Too Big" message to the target RFC4443.
Draft: draft-ietf-masque-connect-udp

Commentary: Should the upgrade token be " connect - udp " or " masque - udp " ? ( issue based on by 
 I vote for or something along those lines . " MASQUE " is good as a working group name , but I do n't think it 's helpful in the protocol to help people understand what the variant of CONNECT does .
This document defines the "masque-udp" HTTP Upgrade Token. "masque-
udp" uses the Capsule Protocol as defined in HTTP-DGRAM.
A "masque-udp" request requests that the recipient establish a tunnel
over a single HTTP stream to the destination target server identified
by the "target_host" and "target_port" variables of the URI template
(see client-config).  If the request is successful, the proxy commits
to converting received HTTP Datagrams into UDP packets and vice versa
until the tunnel is closed.  Tunnels are commonly used to create an
end-to-end virtual connection, which can then be secured using QUIC
QUIC or another protocol running over UDP.
This document defines the "connect-udp" HTTP Upgrade Token. "connect-
udp" uses the Capsule Protocol as defined in HTTP-DGRAM.
A "connect-udp" request requests that the recipient establish a
tunnel over a single HTTP stream to the destination target server
identified by the "target_host" and "target_port" variables of the
URI template (see client-config).  If the request is successful, the
proxy commits to converting received HTTP Datagrams into UDP packets
and vice versa until the tunnel is closed.  Tunnels are commonly used
to create an end-to-end virtual connection, which can then be secured
using QUIC QUIC or another protocol running over UDP.
the request SHALL include a single "Upgrade" header with value
"masque-udp".
the request SHALL include a single "Upgrade" header with value
"connect-udp".
the response SHALL include a single "Upgrade" header with value
"masque-udp".
the response SHALL include a single "Upgrade" header with value
"connect-udp".
The ":protocol" pseudo-header field SHALL be "masque-udp".
The ":protocol" pseudo-header field SHALL be "connect-udp".
This document will request IANA to register "masque-udp" in the HTTP
Upgrade Token Registry maintained at
<<https://www.iana.org/assignments/http-upgrade-tokens>>.
This document will request IANA to register "connect-udp" in the HTTP
Upgrade Token Registry maintained at
<<https://www.iana.org/assignments/http-upgrade-tokens>>.
Draft: draft-ietf-masque-connect-udp

Commentary: This PR pairs with the corresponding HTTP Datagram PR : .
UDP packets are encoded using HTTP Datagrams HTTP-DGRAM.  The payload
of a UDP packet (referred to as "data octets" in UDP) is sent
unmodified in the "HTTP Datagram Payload" field of an HTTP Datagram.
In order to use HTTP Datagrams, the client will first decide whether
or not to use HTTP Datagram Contexts and then register its context ID
(or lack thereof) using the corresponding registration capsule, see
HTTP-DGRAM.
UDP packets are encoded using HTTP Datagrams HTTP-DGRAM with the
UDP_PAYLOAD HTTP Datagram Format Type (see value in iana-format-
type).  When using the UDP_PAYLOAD HTTP Datagram Format Type, the
payload of a UDP packet (referred to as "data octets" in UDP) is sent
unmodified in the "HTTP Datagram Payload" field of an HTTP Datagram.
In order to use HTTP Datagrams, the client will first decide whether
or not to use HTTP Datagram Contexts and then register its context ID
(or lack thereof) using the corresponding registration capsule, see
HTTP-DGRAM.
Extensions to this mechanism MAY leverage the "Context Extensions"
field of registration capsules in order to negotiate different
semantics or encoding for UDP payloads.
Extensions to this mechanism MAY define new HTTP Datagram Format
Types in order to use different semantics or encodings for UDP
payloads.
This document.
Draft: draft-ietf-masque-connect-udp

Commentary: This is partly related to but seems to fit its own issue . Let 's assume a CONNECT - UDP request succeeds with a 2xx and a flow of datagrams is merrily exchanged . How do endpoints indicate they are done with the stream and associated flows ? The spec does n't really say anything . The main example I can think of is where a server decides to perform housekeeping on UDP connections ( maybe as part of runtime garbage collection , or in reaction to the network stack throwing errors ) after a 2xx was been sent . H3 CONNECT says ends the request stream ( that is , the receive stream at the proxy enters the " Data Recvd " state ) , the proxy will set the FIN bit on its connection to the TCP server . When the proxy receives a packet with the FIN bit set , it will close the send stream that it sends to the client . TCP connections that remain half - closed in a single direction are not invalid , but are often handled poorly by servers , so clients SHOULD NOT close a stream for sending while they still expect to receive data from the target of the CONNECT . stream . A proxy treats any error in the TCP connection , which includes receiving a TCP segment with the RST bit set , as a stream error of type H3CONNECTERROR ; see Section 8 . Correspondingly , if a proxy detects an error with the stream or the QUIC connection , it MUST close the TCP connection . If the underlying TCP implementation permits it , the proxy SHOULD send a TCP segment with the RST bit set . Not all of that guidance directly translates but I think it would be helpful to set some expectations for endpoints wrt how stream read or write states might change during the lifetime of a CONNECT - UDP request - especially in the cases where no stream data is being exchanged . 
 I took " FIN or RESET = done " as a given , but it 's worth stating . Proxy behavior will likely be identical in both the graceful and abrupt closure cases .
The lifetime of the socket is tied to the CONNECT-UDP stream.  The
proxy MUST keep the socket open while the CONNECT-UDP stream is open.
Proxies MAY choose to close sockets due to a period of inactivity,
but they MUST close the CONNECT-UDP stream before closing the socket.
The lifetime of the socket is tied to the CONNECT-UDP stream.  The
proxy MUST keep the socket open while the CONNECT-UDP stream is open.
Proxies MAY choose to close sockets due to a period of inactivity,
but they MUST close the CONNECT-UDP stream before closing the socket.
If a proxy is notified by its operating system that its socket is no
longer usable, it MUST close the CONNECT-UDP stream.
Draft: draft-ietf-masque-connect-udp

Commentary: In Sec . 4 it says : If negotiation of HTTP Datagrams fails ( for example if an HTTP/3 SETTINGS frame was received without the H3_DATAGRAM SETTINGS Parameter ) , the client MUST consider its CONNECT - UDP request as failed . IIUC it is entirely possible to do CONNECT - UDP entirely with CAPSULE frames , so I do n't see why a client should fail the attempt because the first hop is H/2 only , or whatever . 
 Thanks for writing this up . I think this is the right solution . I 'll leave this open for some time to see if anyone else would like to comment . To add context : this text predates the creation of capsules , and now CONNECT - UDP works even if QUIC datagram frames are n't available . We 'll want to pick a solution for though . If the H3_DATAGRAM setting also covers capsules we might still need this text . But for now we can remove it .
Since HTTP Datagrams require prior negotiation (for example, in
HTTP/3 it is necessary to both send and receive the H3_DATAGRAM
SETTINGS Parameter), clients MUST NOT send any HTTP Datagrams until
they have established support on a given connection.  If negotiation
of HTTP Datagrams fails (for example if an HTTP/3 SETTINGS frame was
received without the H3_DATAGRAM SETTINGS Parameter), the client MUST
consider its CONNECT-UDP request as failed.
Since HTTP Datagrams require prior negotiation (for example, in
HTTP/3 it is necessary to both send and receive the H3_DATAGRAM
SETTINGS Parameter), clients MUST NOT send any HTTP Datagrams until
they have established support on a given connection.
Draft: draft-ietf-masque-connect-udp

Commentary: This text was a mistake I made when converting from Datagram - Flow - Id to capsules . 
 Section 4 states that the proxy responds to a CONNECT - UDP request with 2xx and a corresponding registration capsule to indicate end - to - end support of datagrams . If the client sends a REGISTERDATAGRAMCONTEXT capsule , the corresponding capsule from the proxy will be of the same kind , and it will register a new server - generated context ID . So now we would have two context IDs for the same stream , which seems a bit unnecessary . Could we simply omit the step where the proxy sends a registration capsule and simply state that a 2xx response to the CONNECT - UDP request is sufficient indication of end - to - end datagram support ? 
 My reading of the spec is different , says So for example , if the client sends a request on stream 4 and then REGISTERDATAGRAMCONTEXT { Context ID ( 0 ) } , the server will respond with    ID ( 0 ) } to confirm that the context is accepted . 
 That makes sense , I was assuming that the " used in both directions " referred to datagrams . I think my confusion in part came from the same section that says : But sending a registration capsule with an already registered context ID is not a new registration I suppose . Maybe it 's good to clarify this a bit in the datagram spec . I 'll open a separate issue there . 
 I agree the draft is a bit ambiguous here . 
 Indeed , the spec is unclear here , my apologies . I got this wrong when I rewrote the old Datagram - Flow - Id text . The server does n't need to echo the registration capsule here since the client 's registration is bidirectional . we should add text to HTTP Datagrams to clarify what we want to do about echoing registrations , is it I 'm leaning towards ( 3 ) unless we have a use case for communicating the fact that a context is " accepted " and in which case I 'd say ( 2 ) . 
 Aha ! In that case I apologise too . This seems important for interop ! Now I remember , I think some people felt registration ack was n't needed as long as there was a way to reject . And we have that with CLOSEDATAGRAMCONTEXT . So I think ( 3 ) , modelled as implicit accept and explicit close , sounds good . That cuts down the chatter ( and probably simplifies some code in my implementation ) .
The proxy that is creating the UDP socket to the destination responds
to the CONNECT-UDP request with a 2xx (Successful) response, and
indicates it supports HTTP Datagrams by sending the corresponding
registration capsule.
The proxy that is creating the UDP socket to the destination responds
to the CONNECT-UDP request with a 2xx (Successful) response.
Draft: draft-ietf-masque-connect-udp

Commentary: On a related note , the text in # performance talks about disabling congestion control on a " connection , " but I believe this is actually a per - endpoint decision . ( The client could easily have more information than the proxy on the tunneled connections ) . 
 Even if CONNECT - UDP has no explicit ECN support without an extension , there is ambiguity relating to copying of ECN bits between ' inner ' and ' outer ' datagrams . MASQUE is not strictly IP - in - IP , though it 's close to it , so it 's not clear if RFC 6040 applies . Nevertheless , I would propose the following principles : ECN markings on the MASQUE connection SHOULD NOT be copied to any resulting UDP datagrams sent by the proxy ; they should apply to the MASQUE connection only . If MASQUE congestion control is disabled per section 9 , it MUST mark all packets non - ECT . ECN markings on incoming UDP datagrams SHOULD NOT be copied to the IP headers of MASQUE packets that encapsulate them : upstream congestion should not affect the congestion state of the MASQUE connection . I 'm happy to write a PR to that effect . 
 When using CONNECT - UDP without extensions , the server - facing UDP sockets on the proxy will not be configured to use ECN , so there will not be any ECN markings on the proxy - server path . In other words , ECN will not be in use , so do we need text about it ? Adding text to clarify this sounds reasonable , but it probably should be generic to anything in the IP header . 
 The extensions explicitly concern markings on DATAGRAM frames in the inner connection . The server may very well be sending packets with ECT(0 ) . With no extension , it will eventually stop , but nevertheless these should n’t appear in MASQUE IP headers . 
 Agreed . I 'll take you up on your offer to write a PR then :) 
 Yes , I think that being clear that for this case the two legs needs to be kept seperate unless internal signalling is used on client to proxy leg to influence the external side setting and receiving of these values . 
 Thanks !
If a client or proxy with a connection containing a CONNECT-UDP
stream disables congestion control, it MUST NOT signal ECN support on
that connection.  That is, it MUST mark all IP headers with the Not-
ECT codepoint.  It MAY continue to report ECN feedback via ACK_ECN
frames, as the peer may not have disabled congestion control.
CONNECT-UDP does not create an IP-in-IP tunnel, so the guidance in
RFC6040 about transferring ECN marks between inner and outer IP
headers does not apply.  There is no inner IP header in CONNECT-UDP
tunnels.
Note that CONNECT-UDP clients do not have the ability in this
specification to control the ECN codepoints on UDP packets the proxy
sends to the server, nor can proxies communicate the markings of each
UDP packet from server to proxy.
A CONNECT-UDP proxy MUST ignore ECN bits in the IP header of UDP
packets received from the server, and MUST set the ECN bits to Not-
ECT on UDP packets it sends to the server.  These do not relate to
the ECN markings of packets sent between client and proxy in any way.