jiebi/CodeConvo huggingface dataset:
Change:
Porting URL originally posted to W3C WT NAME New connections should be throttled to avoid being a DoS vector. Maybe we will just have some language in the standard to permit and encourage throttling, and leave the details to browsers.
Shouldn't the throttling be performed at the W3C layer? If throttling happens, should the W3C API let the caller know?
I think this is a back-to-front way of suggesting that WebTransport include something like the guidance in URL (which I found , linked from URL
Oh thanks for finding that. I'm supportive of adding something like that.
I'm actually not sure that the specific requirement in WebSocket spec is useful, compared to just recommending throttling (or other forms of resource limits) in general.
The WebSocket throttling in RFC6455 requires you to implement it close to the socket layer (in particular, after DNS lookup), which is messy in practice. I think it may be sufficient to leave the details of the throttling to the implementation. If we want to ensure it is interoperable, a per-network-partitiion delay based on the number of pending and recently-failed connections should be sufficient.
So given that this is over HTTP/3, what is the anticipated throttling? Is it really just trying to tell HTTP clients to not make lots of requests? Is WebTransport sufficiently more expensive than other types of requests? I'm struggling to see language we would include here that is needed over language we have in QUIC or HTTP/3 already
Generally a browser will only make one HTTP/3 connection per server, regardless of how many resources the page requests. So servers don't need to worry about a well-behaved browser initiating large numbers of simultaneous QUIC handshakes. However, when WebTransport connections are not pooled, it is valid to make several at the same time. If there were no restrictions, a badly-behaved web page could request thousands of WebTransport connections simultaneously, DoSing the server.
Thanks Adam. I think phrasing thing as a design deviation from HTTP/3's recommendation to use one connection is good idea.
From what I can read from this discussion, there isn't that much in terms of design here, and this mostly requires writing up that throttling is up to the implementation.

Discussion:
within connection gets a reasonable share of controlled resources; this applies both to sending data and to opening new streams. <ins> A client could attempt to exhaust resources by opening too many WebTransport sessions at once.  In cases when the client is untrusted, the user agent SHOULD limit the number of outgoing sessions the client can open. </ins> 8. 8.1.
Change:
currently states: That is not well-defined: it relies on which only discusses HTTP/2, and the relevant changes between HTTP/2 and HTTP/3 are subtle. Since we have that is now in the RFC Editor Queue, WebTransport needs to instead refer to that and require servers to send .
This sounds like an obvious way forward. That said, I would personally prefer to wait until we make another breaking wire protocol change.
Sounds good to me, there's no rush here - in my personal opinion we just need to get this in before WGLC
More generally, it looks like we may want to remove any implied support and just require endpoints to explicitly signal support for each "layer" of capabilities that we're relying on.
Discussed at IETF 115, consensus in room to require all the relevant settings and transport parameters to be sent individually - for this issue means: require that SETTINGSENABLECONNECT_PROTOCOL be sent

Discussion:
3.2. RFC8441 defines an extended CONNECT method in Section 4, enabled by <del> the SETTINGS_ENABLE_CONNECT_PROTOCOL parameter.  That parameter is only defined for HTTP/2.  This document does not create a new multi- purpose parameter to indicate support for extended CONNECT in HTTP/3; instead, the SETTINGS_ENABLE_WEBTRANSPORT setting implies that an endpoint supports extended CONNECT. </del> <ins> the SETTINGS_ENABLE_CONNECT_PROTOCOL setting.  That setting is defined for HTTP/3 by RFC9220.  An endpoint supporting WebTransport over HTTP/3 MUST send both the SETTINGS_ENABLE_WEBTRANSPORT setting and the SETTINGS_ENABLE_CONNECT_PROTOCOL setting with values set to "1". </ins> 3.3.
Change:
This is vaguely based on the similar text in the WebSocket RFC.
In draft 03 the following requirement is made WebTransport's closest equivalent in this regard is WebSockets, which doesn't mandate the origin header; see URL This requirement makes it weird to use for user agents that have no concept of an origin model. So the MUST level seems a bit overzealous.
It is not just the user agent. Take for example the proposed use of . That application does not have any concept of "origin" -- indeed, there is no mention of the word "origin" in that draft.

Discussion:
HTTP CONNECT request.  The ":protocol" pseudo-header field (RFC8441) MUST be set to "webtransport".  The ":scheme" field MUST be "https". Both the ":authority" and the ":path" value MUST be set; those fields <del> indicate the desired WebTransport server.  An "Origin" header RFC6454 MUST be provided within the request. </del> <ins> indicate the desired WebTransport server.  If the WebTransport session is coming from a browser client, an "Origin" header RFC6454 MUST be provided within the request; otherwise, the header is OPTIONAL. </ins> Upon receiving an extended CONNECT request with a ":protocol" field set to "webtransport", the HTTP/3 server can check if it has a
Change:
This is mostly based on what Chrome currently does in production.
Chair: discussed during editor's meeting, plan is to remove text about 3 PTO and note that delivering other open streams is best-effort. Also add rationale and mention that this aligns with what QUIC does - this message has similar delivery guarantees as the close_connection in QUIC
A common use (at least for non-pooled WebTransport connections) will be to close the underlying QUIC connection when closing the WebTransport session. This is inherently racy: The sender will send both a CLOSEWEBTRANSPORTSESSION capsule and a QUIC CONNECTIONCLOSE frame (unless you wait for the peer's FIN on the request stream, but why would you?). It's undetermined which one of the two will be received / processed first by the receiver. This is not a problem if the sender uses the same error code and error message for the CONNECTIONCLOSE frame and for the CLOSEWEBTRANSPORTSESSION capsule. Assuming the QUIC stack properly exposes these values on its API, the receiver will be able to learn error code and error message. Should we add that as a recommendation, or even a requirement?
Chair: discussed during editor's meeting, see URL

Discussion:
to terminating it with a CLOSE_WEBTRANSPORT_SESSION capsule that has an error code of 0 and an empty error string. <ins> In some scenarios, an endpoint might want to send a CLOSE_WEBTRANSPORT_SESSION with detailed close information and then immediately close the underlying QUIC connection.  If the endpoint were to do both of those simultaneously, the peer could potentially receive the CONNECTION_CLOSE before receiving the CLOSE_WEBTRANSPORT_SESSION, thus never receiving the application error data contained in the latter.  To avoid this, the endpoint SHOULD wait until all of the data on the CONNECT stream is acknowledged before sending the CONNECTION_CLOSE; this gives CLOSE_WEBTRANSPORT_SESSION properties similar to that of the QUIC CONNECTION_CLOSE mechanism as a best-effort mechanism of delivering application close metadata. </ins> 6. [[RFC editor: please remove this section before publication.]]
Change:
This updates the IANA considerations section for Frame Type to match URL, by including "server-initiated" in the type of bidirectional streams allowed by the frame.

Discussion:
The following entry is added to the "HTTP/3 Frame Type" registry established by HTTP3: <del> The "WEBTRANSPORT_STREAM" frame allows HTTP/3 client-initiated bidirectional streams to be used by WebTransport: </del> <ins> The "WEBTRANSPORT_STREAM" frame allows HTTP/3 client-initiated and server-initiated bidirectional streams to be used by WebTransport: </ins> 0x41
Change:
After sending the CLOSEWEBTRANSPORTSESSION capsule and sending the FIN on the stream, it would make sense to also stop reading on the stream (by sending a STOP_SENDING). Should that be the recommended behavior in the spec?
Chair: discussed at IETF 114, consensus in the room to allow but not require sending STOP_SENDING
The spec currently reads: So it currently recommends setting a timer and then issuing a STOPSENDING. I guess the request here is to send indicate the sender of CLOSEWEBTRANSPORTSESSION may send the STOPSENDING immediately. I'm going to remove the bit about the timer since it's not really relevant? If the closing endpoint wants to wait to see if there's any other messages in flight on the CONNECT stream that's fine. The CLOSEWEBTRANSPORTSESSION + FIN + must-respond-with-FIN is an implicit STOP_SENDING.
Fix the typo, raise an issue for the other thing.

Discussion:
closing the connection.  The message takes up the remainder of the capsule, and its length MUST NOT exceed 1024 bytes. <del> A CLOSE_WEBTRANSPORT_SESSION capsule MUST be followed by a FIN on the sender side.  If any additional stream data is received on the CONNECT stream after CLOSE_WEBTRANSPORT_SESSION, the stream MUST be reset with code H3_MESSAGE_ERROR.  The recipient MUST close the stream upon receiving a FIN.  If the sender of CLOSE_WEBTRANSPORT_SESSION does not receive a FIN after some time, it SHOULD send STOP_SENDING on the CONNECT stream. </del> <ins> An endpoint that sends a CLOSE_WEBTRANSPORT_SESSION capsule MUST immediately send a FIN.  The endpoint MAY send a STOP_SENDING to indicate it is no longer reading from the CONNECT stream.  The recipient MUST close the stream upon receiving a FIN.  If any additional stream data is received on the CONNECT stream after receiving a CLOSE_WEBTRANSPORT_SESSION capsule, the stream MUST be reset with code H3_MESSAGE_ERROR. </ins> Cleanly terminating a CONNECT stream without a CLOSE_WEBTRANSPORT_SESSION capsule SHALL be semantically equivalent
Change:
Added some precisions on the research section. When authors improve throughput by hiding the congestion signal, I propose to compare using FEC to hide the congestion signal with replacing the current congestion control by one that similarly ignores the loss signal without using any FEC. Concerning the solutions proposing to disambiguate the ACKs from the recoveries, I cited QUIC-FEC. We should also cite TENTET. NAME do you have a reference of an article about TENTET ? Do not hesitate to suggest changes before merging.
That looks very fine to me! We may just be missing the reference to tentet before merging the branch

Discussion:
amount of redundancy to add, as a function of the transport layer protocol and application requirements. <del> For the FEC within transport case, the addition of coding may hide congestion losses and proposing methods to signal such events to end point could be propose. </del> <ins> For the FEC within transport case, recovering lost symbols may hide congestion losses to the congestion control.  Some existing solutions already propose to disambiguate acked packets from rebuilt packets QUIC-FEC.  New signalling methods and FEC-recovery-aware congestion controls could be proposed. </ins> For the FEC below transport case, there are opportunities for introducing interaction between congestion control and coding schemes

proposing and comparing FEC coding solutions in communication systems.  As one example, this draft proposes discussions on the impact of the proposed FEC solution on the congestion control, <del> especially loss-based congestion control such as CUBIC. </del> <ins> especially loss-based congestion control such as CUBIC.  When a research work aims at improving the throughput by hiding the packet loss signal from the congestion control, the authors should 1) discuss the advantages of using the proposed FEC solution compared to replacing the congestion control by one that ignores a portion of the encountered losses, 2) critically discuss the impact of hiding packet loss from the congestion control mechanism. </ins> 8.
Change:
There are two possibilities either: "Point-to-point transmetting method based on the use of an erasure coding scheme and TCP/IP protocol", ISAE-SUPAERO (2019) EP 3 432 500 A1, WO 2019015931 (A1). URL "On the joint use of TCP and Network Coding", Emmanuel Lochin, IETF'100 NWCRG session, November 2017. URL
Since this is IPR protected content I gather the IPR declaration is up to date?
Yes Le mer. 28 oct. 2020 à 10:40, patibulon a écrit :
done in PR

Discussion:
control, it may be possible to signal to the congestion control mechanism that there was congestion (loss) even when a packet has been recovered, e.g. using ECN, to reduce the impact on the non-coded <del> flows (see subsec:cc-recov-inter-below). </del> <ins> flows (see subsec:cc-recov-inter-below and TENTET). </ins> 6.3.

recovered is to exploit existing signaling that is understood by the congestion control mechanism.  An example would be to indicate to a TCP sender that a packet has been recovered (i.e., congestion has <del> occurred), by using ECN signaling. </del> <ins> occurred), by using ECN signaling TENTET. </ins> 6.4.
Change:
Just corrected legitimize.
legitimate -> legitimize. This entire section is unnecessary. With this draft on a multi-gateway satellite system and DVB, you're talking about geostationary satellites which are always visible. Little disruption. 600ms or so delay is coped with by Internet protocols (RFC829 SATNET work etc.) So, not a significant delay issue either. It's out of scope for the abstract. And geostationary satellites generally don't use CCSDS for broadband; TDRSS is so much a special case. Since we're not standards track, References aren't split informative/normative -- but given the DVB starting point, I'd expect to see more DVB-S references. EN 302 307, which details extensions of the original satellite transmission standard DVB-S (EN 300 421), etc.
We need to discuss this point. Just corrected legitimize in

Discussion:
Coding enables E2E reliable communication over DTN with adaptive re- encoding, as proposed in THAI15.  In this case, the use-cases <del> proposed in subsec:varying would legitimate the usage of coding </del> <ins> proposed in subsec:varying would legitimize the usage of coding </ins> within the DTN stack to improve the channel utilization and the E2E transmission delay.  In this context, the use of erasure coding inside a Consultative Committee for Space Data Systems (CCSDS)
Change:
ACM : Adaptative Coding and Modulation; -- Adaptive. This error repeats. CPE: Customer Premise Equipment; -- Premises. (My premise is that this is unfortunate.) FEC: Forward Erasure Correction;-- FEC is traditionally Error. Redefining industry terms to suit your network coding case won't help. FLUTE: File Delivery over Unidirectional Transport;-- just ref RFC6726. bit of a pointless inclusion imo. PEP: Performance Enhanced Proxy [RFC3135]-- the title of RFC3135 is perfectly clear that it's Enhancing and the word 'Enhanced' does not appear in that document. This is not the sort of thing WGLC is for. PLFRAME - see below. Odd to see mention of PLFRAME but not FECFRAME, which is a more direct translation of the packet data.
I have corrected the accronyms in PR We do not mention FECFRAME because it is an internal format and we focus on what is exchanged between access and physical gateways.

Discussion:
The glossary of this memo extends the glossary of the taxonomy document RFC8406 as follows: <del> ACM : Adaptative Coding and Modulation; </del> <ins> ACM : Adaptive Coding and Modulation; </ins> BBFRAME: Base-Band FRAME - satellite communication layer 2 encapsulation work as follows: (1) each layer 3 packet is

contain information related to how they have to be modulated (4) BBFRAMEs are forwarded to the physical-layer; <del> CPE: Customer Premise Equipment; </del> <ins> CPE: Customer Premises Equipment; </ins> COM: COMmunication;

ETSI: European Telecommunications Standards Institute; <del> FEC: Forward Erasure Correction; </del> <ins> FEC: Forward Error Correction; </ins> FLUTE: File Delivery over Unidirectional Transport;

NORM: NACK-Oriented Reliable Multicast; <del> PEP: Performance Enhanced Proxy RFC3135 - a typical PEP for </del> <ins> PEP: Performance Enhancing Proxy RFC3135 - a typical PEP for </ins> satellite communications include compression, caching and TCP acceleration;
Change:
The way it's said may call for comments during SecDir review. I'd rather say: Security considerations are inherent to any access network, and in particular SATCOM systems. The use of FEC or Network Coding in SATCOM also comes with risks (e.g., a single corrupted redundant packet may propagate to several flows when they are protected togething in an Inter-Flow coding approach, see section 3). However this is not specific to the SATCOM use-case and this document does not further elaborate on it.
Thanks for this suggestion. Closed by PR

Discussion:
8. <del> Security considerations are inherent to any access network.  SATCOM systems introduce standard security mechanisms.  On the specific scenario of NC in SATCOM systems, there are no specific security considerations. </del> <ins> Security considerations are inherent to any access network, and in particular SATCOM systems.  The use of FEC or Network Coding in SATCOM also comes with risks (e.g., a single corrupted redundant packet may propagate to several flows when they are protected togething in an Inter-Flow coding approach, see section sec:use_cases).  However this is not specific to the SATCOM use-case and this document does not further elaborate on it. </ins>
Change:
"We have noticed an active research activity on coding and SATCOM in the past." -- if it's active, it's not in the past. if it's in the past, it's not active. Do you mean 'in the past we have noticed'? that's redundant.
You are right. This leads to some confusion. We propose to change as in PR

Discussion:
opportunity for releasing constraints on the physical layer and improving the performance of SATCOM systems. <del> We have noticed an active research activity on coding and SATCOM in the past.  That being said, not much has actually made it to industrial developments.  In this context, this document aims at identifying opportunities for further usage of coding in these systems. </del> <ins> We notice an active research activity on coding and SATCOM.  That being said, not much has actually made it to industrial developments. In this context, this document aims at identifying opportunities for further usage of coding in these systems. </ins> This document follows the taxonomy of coding techniques for efficient network communications RFC8406.
Change:
John Border: Forward Error Correction (FEC) coding below the network layer takes us a long way. At the same time, I think network coding has a lot to offer re reducing retransmission delay when the FEC coding is not enough. I do see that the referenced taxonomy document includes Forward Erasure Correction. This “FEC” is described as an application layer technique. The overlapping use of “FEC” is unfortunate for those of who work down at the lower layers. In any case, it is not always clear which “FEC” the document is referring to.
I understand that there is some confusion on the usage of the accronym. We have clarified in the document that "Following the taxonomy document [RFC8406], channel and link codings are gathered in the PHY layer coding and are out of the scope of this document." We have added in PR that this document considers FEC above the network layer.

Discussion:
that the physical-layer knows what coding scheme to use.  Following the taxonomy document RFC8406, channel and link codings are gathered in the PHY layer coding and are out of the scope of this document. <ins> This document considers FEC as coding mechanisms above the network layer only. </ins> fig:existing_network presents the status of the reliability schemes deployment in satellite systems.

discussions. X2 embodies the physical-layer, applied to the PLFRAME, to <del> optimize the satellite capacity usage.  At the physical layer, FEC mechanisms can be exploited. </del> <ins> optimize the satellite capacity usage.  At the physical layer, other coding mechanisms can be exploited. </ins> Reliability is an inherent part of the physical-layer and usually achieved by using coding techniques.  Based on public information,
Change:
Answer to issue
John Border: Section 4.2, 2nd Paragraph "Unidirectional" implies (to me) no ACKs. Without ACKs, FLUTE must do repair in such a way as to not need to know exactly what was lost. This seems different enough to me to be explained separate from NORM.
Our objective is not to discuss about NORM and FLUTE, which is out of scope of the document. We cite these protocols as possible usage example. Also note that although FLUTE is unidirectional, the RFC keeps a door open proposing bidirectional communications for security purpose and to enable full reliability transfer. As a result, we move this sentence at the end of this section as a complementary material and completed the FLUTE description.

Discussion:
this scenario in fig:rel_multi. A multicast flow (M) is forwarded to both satellite terminals A and <del> B.  However packet Ni (resp.  Nj) get lost at terminal A (resp.  B), </del> <ins> B.  However packet Ni (resp.  Nj) gets lost at terminal A (resp.  B), </ins> and terminal A (resp.  B) returns a negative acknowledgment Li (resp. Lj), indicating that the packet is missing.  Then either the access gateway or the multicast server includes a repair packet (rather than

feedback link is available, or File Delivery over Unidirectional Transport (FLUTE) RFC6726 otherwise.  Note that both NORM and FLUTE are limited to block coding, none of them supporting sliding window <del> encoding schemes RFC8406. </del> <ins> encoding schemes RFC8406.  Note that although FLUTE is defined as an unidirectional protocol, the RFC proposes a bidirectional communication method to enable full reliability transfer and for security purpose. </ins> 4.3.