jiebi/CodeConvo huggingface dataset:
Change:
This section deserves a small introduction where you explain that you discuss a few topics, without trying to be exhaustive. Section 5.1 Are PEP part of "Network Functions"? What's their position in the architecture of Fig. 1?I don't understand why the question on code rate to use is in a challenge called "increased deployability". I'd rather put it in a challenge on dynamic adaptation (which is not identified).
Corrected and answered in PR

Discussion:
SATCOM systems typically feature Performance Enhancement Proxy (PEP) RFC3135.  PEP usually split TCP end-to-end connections and forward TCP packets to the satellite baseband gateway that deals with layer-2 <del> and layer-1 encapsulations.  PEP could host coding techniques and thus support the use-cases that have been discussed in this document. </del> <ins> and layer-1 encapsulations.  PEP contributes to mitigate congestion in a SATCOM systems.  PEP could host coding mechanisms and thus support use-cases that have been discussed in this document. </ins> Deploying coding schemes at the TCP level in these equipment could be relevant and independent from the specific characteristics of a <del> SATCOM link.  However, there is a research issue in the recurrent trade-off in SATCOM systems: how much overhead from redundant reliability packets can be introduced to guarantee a better end-user QoE while optimizing capacity usage ? </del> <ins> SATCOM link.  This leads to research question on the interaction between coding schemes and TCP congestion controls. </ins> 4.2. <ins> The recurrent trade-off in SATCOM systems remains: how much overhead from redundant reliability packets can be introduced to guarantee a better end-user QoE while optimizing capacity usage ? 4.3. </ins> Related to the foreseen virtualized network infrastructure, coding techniques could be easily deployed as VNF.  Next generation of SATCOM ground segments could rely on a virtualized environment.  This

to a virtualized SATCOM terminals is the management of limited buffered equipments. <del> 4.3. </del> <ins> 4.4. </ins> In the context of the deep-space communications, establishing communications from terrestrial gateways to satellite platforms can
Change:
abstract This memo details a multi-gateway satellite system to identify multiple opportunities on how network coding techniques could be deployed at a wider scale. this is talking about network coding, and this draft needs to be perfectly clear throughout that it is doing so, otherwise people who know and use other coding and have had little use for network coding previously will simply stop reading. Blurring the coding case is not helping your cause. I called this out previously. This is important.
Vincent: Abstract: The current abstract is not sufficiently detailed: which type of coding? Do you refer to FEC or NC (say so) since it may also be used for other types of coding. The notion of "wider scale" also suggests it is already deployed (is it the case?), or that it may be used outside of the multi-gateway satellite system itself. On the whole, this abstract is pretty ambiguous.
abstract must mention the origin. This document is the product of the Coding for Efficient Network Communications Research Group (NWCRG).
We have rephrased the whole abstract and we think PR cover this issue.

Discussion:
Abstract <del> This memo details a multi-gateway satellite system to identify multiple opportunities on how coding techniques could be deployed at a wider scale. </del> <ins> This document is the product of the Coding for Efficient Network Communications Research Group (NWCRG).  This document follows the taxonomy document RFC8406 and considers coding as a linear combination of packets that operate above the network layer.  In this context, this memo details a multi-gateway satellite system to identify use-cases where coding is relevant.  As example, coding operating above the network layer can be exploited to cope from residual losses or provide reliable multicast services.  The objective is to contribute to a larger deployment of such techniques in SATCOM systems.  This memo also identifies open research issues related to the deployment of coding in SATCOM systems, such as the interaction between congestion controls and coding techniques. </ins> 1.
Change:
Introduction physical-layer reliability mechanisms -- hyphenate adjectival terms style: e.g. should be in a clause separated by commas, not brackets. 500 ms one-way delivery delay (or path -- i.e. not propagation)
Intro must do the same, clarifying also it's not a standard, and give an estimation of the support it collected during discussion within the group. For instance (taken from rfc 8406): This document is the product of and represents the collaborative work and consensus of the Coding for Efficient Network Communications Research Group (NWCRG); it is not an IETF product and is not a standard. .
I think PR solves the issue.

Discussion:
acceleration; PLFRAME: Physical Layer FRAME - modulated version of a BBFRAME <del> with additional information (e.g. related to synchronization); </del> <ins> with additional information (e.g., related to synchronization); </ins> QEF: Quasi-Error-Free;

VNF: Virtual Network Function. <ins> This document is the product of and represents the collaborative work and consensus of the Coding for Efficient Network Communications Research Group (NWCRG); it is not an IETF product and is not a standard. </ins> 2. This section describes the components in a satellite system based on

3. This section details use-cases where coding techniques could improve <del> the overall performance of a SATCOM system (e.g. considering a more </del> <ins> the overall performance of a SATCOM system (e.g., considering a more </ins> efficient usage of the satellite resource, delivery delay, delivery ratio).

This use-case is mostly relevant for when mobile users are considered or when the chosen band induce a required physical-layer coding that may change over time (Q/V bands, Ka band, etc.).  Depending on the <del> use-case (e.g. very high frequency bands, mobile users) or depending on the deployment use-cases (e.g. performance of the network between </del> <ins> use-case (e.g., very high frequency bands, mobile users) or depending on the deployment use-cases (e.g., performance of the network between </ins> each individual block), the relevance of adding coding techniques is different.
Change:
this is cherrypicking, not discussing link/channel FEC (Error) or ACK. the heading should really be 'of network coding schemes'. "to cover cases where where"? At the physical layer, FEC mechanisms can be exploited.-- Erasure or Error? "Based on public information, coding does not seem to be widely used at higher layers." it isn't, and that section can be reduced to just that sentence.
Vincent in item X1, 1st sentence, it suggests QUIC is a video streaming application. Change it.Fig. 2 raises a general question: it refers to upper applications that are by nature on the end-hosts. Everything is imaginable here and this is not specific to a SATCOM system. Why don't you limit yourself to the communication layers + middleware? I'm a bit confused.When you say: "Based on public information, coding does not seem to be widely used at higher layers." I guess you limit yourself to the "packetization UDP/IP + middleware" but do not consider upper applications. It's also confusing.
We think that these comments have been assessed with PR

Discussion:
deployment in satellite systems. X1 embodies the source coding techniques that could be used at <del> application level for instance within QUIC or other video streaming applications.  This is not specific to SATCOM systems since such deployment can be relevant for broadband Internet access discussions. </del> <ins> application level for instance within QUIC.  This is not specific to SATCOM systems since such deployment can be relevant for broadband Internet access discussions. </ins> X2 embodies the physical-layer techniques exploited in SATCOM systems (note that other coding techniques can be exploited).
Change:
Q (Dave Oran): in or above network layer (above means no re-encoding in the router)? A: both - and the document is clear about it - no layer 2 coding. Q (Stew Card): what are the "C" is the architecture picture? A: this is where we could put the coding.
Done with PR and

Discussion:
Channel and link codings are gathered in the PHY layer coding and are out of the scope of this document. <del> FEC (also called Application-Level FEC) operate above the network layer. </del> <ins> FEC (also called Application-Level FEC) operate in and above the network layer. </ins> This document considers coding (or coding techniques or coding schemes) as a linear combination and not as a content coding
Change:
I'm puzzled as to how this document claims that channel and link codings are out of scope - and then talks about channel mode, dealing with varying channel conditions (yet without using channel codings), etc. They're stated as out of scope...
If the intent is treating the overall end-to-end path as some sort of virtual 'channel' that coding packets are applied to, this needs to be said explicitly upfront. If 'channel' means more than one concatenated physical path here, this needs to be said. Unless your audience is only network coding people... the title should likely be 'network coding applicability to satellite-based scenarios' or similar, too. Needs to be really specific for clarity.
In PR , we have changed: "Channel and link codings are gathered in the PHY layer coding and are out of the scope of this document." by "Channel and link codings are gathered in the PHY layer coding and are out of the scope of this document. It focuses on situations where coding is not widely deployed in current SATCOM systems." For the comment on the end-to-end path, the notion of virtual 'channel' depends on the use-case and coding is not applied at the same level. For the title, we have moved from "Network coding and satellites" to "Coding techniques for satellite systems" from version 04 and 05 of the document to be more generic. I guess we should not go back to the "network coding"-like title.

Discussion:
document RFC8406: Channel and link codings are gathered in the PHY layer coding and <del> are out of the scope of this document. </del> <ins> are out of the scope of this document.  It focuses on situations where coding is not widely deployed in current SATCOM systems. </ins> FEC (also called Application-Level FEC) operates in and above the network layer.
Change:
section 4.1 - PEP is Enhancing, not Enhancement. PEPs usually split... section 4.2 - quickly varying channel conditions - if on the satellite link (where discussing channel conditions is out of scope?) that's what ACM, which is defined in the glossary, does -- and where network coding does not do as well. ASMS - spell out the conference name. No need to abbreviate journal names - this isn't an academic paper with a page limit. Do provide document object idenitifiers (DOIs) of papers where they exist
Thanks for the nits on the PEP. For the comment on ACM, we have updated the text (PR ) : "This problem has been tackled in the past for physical-layer code, but there remains questions on how to adapt the overhead for, e.g., the quickly varying channel conditions use-case where ACM may not be reacting quickly enough." We have updated the conference in PR and PR

Discussion:
4.1. <del> SATCOM systems typically feature Performance Enhancement Proxy (PEP) RFC3135.  PEP usually split TCP end-to-end connections and forward </del> <ins> SATCOM systems typically feature Performance Enhancing Proxy (PEP) RFC3135.  PEPs usually split TCP end-to-end connections and forward </ins> TCP packets to the satellite baseband gateway that deals with layer-2 and layer-1 encapsulations.  PEP contributes to mitigate congestion in a SATCOM systems.  PEP could host coding mechanisms and thus

This problem has been tackled in the past for physical-layer code, but there remains questions on how to adapt the overhead for, e.g., <del> the quickly varying channel conditions use-case. </del> <ins> the quickly varying channel conditions use-case where ACM may not be reacting quickly enough. </ins> 4.3.
Change:
As in the , We should document how we provide a unidirectional stream, likely by adding that as a parameter to the Connect stream.
Looking good! Few minor formatting nits, but nothing major.

Discussion:
The WTHEADERS frame (type=0xfb) has all the fields and frame header flags defined by HEADERS frame in HEADERS RFC7540, Section 6.2. <ins> The WTHEADERS frame has an additional flag, Unidirectional (0x40). When this flag is present, the stream starts in a half-closed state. The sending endpoint stream state is "half-closed (remote)" and the receiving endpoint state is "half-closed (local)". </ins> The WTHEADERS frame has one extra field, Connect Stream ID. WTHEADERS frames can be sent on a stream in the "idle", "open", or "half-closed (remote)" state, see stream-states.
Change:
This might seem unfortunate, but it's how the protocol works. Update the link to point to HTTP spec instead.

Discussion:
2. <del> WebTransport servers are identified by a pair of authority value and path value (defined in RFC3986 Sections 3.2 and 3.3 correspondingly). </del> <ins> WebTransport servers are identified by an HTTPS URI as defined in Section 4.2.2 of HTTP. </ins> When an HTTP/2 connection is established, both the client and server have to send a SETTINGS_ENABLE_WEBTRANSPORT setting in order to
Change:
There was a local reference that was just typed out. The references to other documents cargo-culted from QUIC, but that only works if the documents are in the same repo. You have to pull references from the datatracker. Use the nice reference format in a few places.

Discussion:
3.2. <del> RFC8441 defines an extended CONNECT method in Section 4, enabled by </del> <ins> RFC8441 defines an extended CONNECT method in features, enabled by </ins> the SETTINGS_ENABLE_CONNECT_PROTOCOL parameter.  An endpoint does not need to send both SETTINGS_ENABLE_CONNECT_PROTOCOL and SETTINGS_ENABLE_WEBTRANSPORT; the SETTINGS_ENABLE_WEBTRANSPORT

In order to create a new WebTransport session, a client can send an HTTP CONNECT request.  The ":protocol" pseudo-header field (RFC8441) <del> MUST be set to "webtransport" (Section 7.1 WEBTRANSPORT-H3).  The </del> <ins> MUST be set to "webtransport" (Section 7.1 of WEBTRANSPORT-H3).  The </ins> ":scheme" field MUST be "https".  Both the ":authority" and the ":path" value MUST be set; those fields indicate the desired WebTransport server.  An "Origin" header RFC6454 MUST be provided
Change:
Two things: Say what the header contains Limit it to the Web And fix the xref formatting.

Discussion:
MUST be set to "webtransport" (Section 7.1 of WEBTRANSPORT-H3).  The ":scheme" field MUST be "https".  Both the ":authority" and the ":path" value MUST be set; those fields indicate the desired <del> WebTransport server.  An "Origin" header { {!RFC6454}} MUST be provided within the request. </del> <ins> WebTransport server.  In a Web context, the request MUST include an "Origin" header field ORIGIN that includes the origin of the site that requested the creation of the session. </ins> Upon receiving an extended CONNECT request with a ":protocol" field set to "webtransport", the HTTP server can check if it has a
Change:
The resource does. It's a fine distinction, but an important one.
An excellent distinction, thank you :)

Discussion:
that requested the creation of the session. Upon receiving an extended CONNECT request with a ":protocol" field <del> set to "webtransport", the HTTP server can check if it has a WebTransport server associated with the specified ":authority" and ":path" values.  If it does not, it SHOULD reply with status code 404 (Section 6.5.4,RFC7231).  If it does, it MAY accept the session by replying with status code 200.  The WebTransport server MUST verify the "Origin" header to ensure that the specified origin is allowed to access the server in question. </del> <ins> set to "webtransport", the HTTP server checks if the identified resource supports WebTransport sessions.  If the resource does not, the server SHOULD reply with status code 404 (Section 6.5.4 of RFC7231).  To accept a WebTransport session the server replies with 2xx status code.  Before accepting a session, a server MUST ensure that it authorizes use of the session by the site identified in the "Origin" header. </ins> From the client's perspective, a WebTransport session is established when the client receives a 200 response.  From the server's
Change:
The frame format depends on having a definition. I've also made a requirement for this to be zero values. Do we need to say that recipients MUST NOT validate this or that they MAY opt to avoid validation.

Discussion:
frames and can also be used to provide protection against traffic analysis or for other reasons. <del> The padding extends to the end of the WT_PADDING frame and that many bytes can be discarded by the recipient. </del> <ins> The Padding field MUST be set to an all-zero sequence of bytes of any length as specified by the Length field. </ins> 5.2.
Change:
There is not "right" place to put these, but as they are fairly large (and not that useful, frankly), I am going to suggest that they go after the frame definitions.
Yeah, these used to describe how you'd handle a bunch of new concepts, this is now pretty basic and not particularly enlightening. Mayyyybe useful for the establishment, if you've never seen Extended CONNECT, but... yeah. Seems good to move around now and we can cut it later if we don't end up adding anything useful to them. (I also updated with the section reference change from the other PRs to fix up conflicts, since this moved one of those)
I think these have evolved through various versions of the drafts. When the original draft was presented, things like a "CONNECT stream" and how other streams relate to it were not common knowledge, so the examples were maybe more useful. If everyone has got the idea, we can drop it.

Discussion:
6. <ins> An example of negotiating a WebTransport Stream on an HTTP/2 connection follows.  This example is intended to closely follow the example in Section 5.1 of RFC8441 to help illustrate the differences defined in this document. An example of the server initiating a WebTransport Stream follows. The only difference here is the endpoint that sends the first WT_STREAM frame. 7. </ins> An WebTransport session over HTTP/2 is terminated when either endpoint closes the stream associated with the CONNECT request that initiated the session.  Upon learning about the session being terminated, the endpoint MUST stop sending new datagrams and reset all of the streams associated with the session. <del> 7. </del> <ins> 8. </ins> The WebTransport framework OVERVIEW defines a set of optional transport properties that clients can use to determine the presence

TLS.  Without such support, Http2Transport connections cannot survive network transitions. <del> 8. </del> <ins> 9. </ins> WebTransport over HTTP/2 satisfies all of the security requirements imposed by OVERVIEW on WebTransport protocols, thus providing a

within connection gets a reasonable share of controlled resources; this applies both to sending data and to opening new streams. <del> 9. </del> <ins> 10. </ins> <del> 9.1. </del> <ins> 10.1. </ins> The following entry is added to the "HTTP/2 Settings" registry established by RFC7540:

This document <del> 9.2. An example of negotiating a WebTransport Stream on an HTTP/2 connection follows.  This example is intended to closely follow the example in Section 5.1 of RFC8441 to help illustrate the differences defined in this document. An example of the server initiating a WebTransport Stream follows. The only difference here is the endpoint that sends the first WT_STREAM frame. 10.  References </del> <ins> 11.  References </ins> <del> 10.1.  URIs </del> <ins> 11.1.  URIs </ins> [1] mailto:webtransport@ietf.org
Change:
Attempting to be minimal and just point at RFC9000.
Do we talk about the stream ID numbering space here? It could be completely scoped to the WebTransport session, which is different than H3. Originally posted by NAME in URL
Thanks for doing that.

Discussion:
4.2. <del> WebTransport streams have states that mirror the states of QUIC streams (Section 3 of RFC9000) as closely as possible to aid in ease of implementation. </del> <ins> WebTransport streams have identifiers and states that mirror the identifiers ((Section 2.1 of RFC9000)) and states (Section 3 of RFC9000) of QUIC streams as closely as possible to aid in ease of implementation. WebTransport streams are identified by a numeric value, or stream ID. Stream IDs are only meaningful within the WebTransport session in which they were created.  They share the same semantics as QUIC stream IDs, with client initiated streams having even-numbered stream IDs and server-initiated streams having odd-numbered stream IDs. Similarly, they can be bidirectional or unidirectional, indicated by the second least significant bit of the stream ID. </ins> Because WebTransport does not provide an acknowledgement mechanism for WebTransport frames, it relies on the underlying transport's in
Change:
woohoo, making real progress!
The HTTP/2 draft uses "using". This one uses "over". This looks bad in my (sidebar) browser tabs.
HTTP/3 draft describes itself as "a mapping of HTTP semantics over QUIC", so I moderately prefer "over" based on that precedent (and well, the fact that all drafts that I wrote use "over").

Discussion:
<del> WebTransport using HTTP/2 </del> <ins> WebTransport over HTTP/2 </ins> draft-ietf-webtrans-http2-latest Abstract
Change:
I don’t agree with this. A client can send a request body without awaiting a response. Always. Originally posted by NAME in URL
Are those concerns orthogonal? I don't believe there is anything in the text that says you cannot send data before the session is established.
I don't think that this is necessary, or helpful. And I don't think that you can police it either. It is true that a client cannot initiate any streams before the session is created (because the stream limits start at zero), but I see no reason not to pipeline WTDATAGRAM or MAX frames if the h2-level flow control permits it. The MAX_ frames are particularly useful in that they allow the server to send real data immediately, cutting a round trip off.
Given that the limits start at zero (do we state that explicitly anywhere?), and we're not including any sort of SETTINGS/default settings, it definitely seems like we ought to be able to just start spewing frames into the CONNECT stream, which are discarded if the CONNECT request is rejected.
Chair: discussed at 113, consensus in room to allow sending any frames allowed by flow control
Text in H3 here: URL, can probably make it look similar for H2.

Discussion:
WebTransport server MUST verify the "Origin" header to ensure that the specified origin is allowed to access the server in question. <del> From the client's perspective, a WebTransport session is established when the client receives a 200 response.  From the server's perspective, a session is established once it sends a 200 response. Both endpoints MUST NOT send any WebTransport capsules on a given session before that session is established. </del> <ins> A WebTransport session is established when the server sends a 200 response.  A server generates that response from the request header, not from the contents of the request.  To enable clients to resend data when attempting to re-establish a session that was rejected by a server, a server MUST NOT process any capsules on the request stream unless it accepts the WebTransport session. A client MAY optimistically send any WebTransport capsules associated with a CONNECT request, without waiting for a response, to the extent allowed by flow control.  This can reduce latency for data sent by a client at the start of a WebTransport session.  For example, a client might choose to send datagrams or flow control updates before receiving any response from the server. </ins> 3.4.