jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-irtf-nwcrg-coding-and-congestion-07

Commentary: Looks good to me , thanks for doing this !
The application layer may be composed of several streams above FEC
and transport layers instances.  The different streams could exploit
different paths between the sender and the receiver or not.  The
document considers one application layer stream as input packets
above a combination of FEC and transport layers.  The case of
multiple application level streams above multiple FEC and transport
layers instances is out of the scope of the document and not further
described.
The application layer may be composed of several streams above FEC
and transport layers instances.  The different streams could exploit
different paths between the sender and the receiver or not.  The
document considers one application layer stream as input packets
above a combination of FEC and transport layers.  In fig:multi-scope,
each of stream 1 and stream 2 are considered in the scope of the
document but a combination of stream 1 and stream 2 is not.  The case
of multiple application level streams above multiple FEC and
transport layers instances is out of the scope of the document and
not further described.
Draft: draft-irtf-nwcrg-coding-and-congestion-05

Commentary: Great job , thanks for doing this ! I made a few suggestions , all minor things .
We consider an end-to-end unicast data transfer with FEC coding at
the application (above the transport), within the transport or
directly below the transport.  The typical application scenario
considered in the current version of the document is a client
browsing the web or watching a live video.  This memo may be extended
to cases with multiple paths.
We consider an end-to-end unicast data transfer with FEC coding at
the application (above the transport), within the transport or
directly below the transport.  The typical application scenario
considered in the current version of the document is a client
browsing the web or watching a live video.
The document considers one application layer stream as input packets.
The application layer may exploit several paths above both the FEC
and transport layers; this case is not further described in the
document.
Whether the transport protocol exploits multiple paths or not does
not have an impact on the FEC mechanism.
The sender may adapt the coding rate of each of the single subpaths,
whether the congestion control is coupled or not.  There is an
important flexibility on how the coding rate is tuned depending on
the characteristics of each subpath.
The transport may exploit multiple paths without the FEC channel
being aware of it.  This depends on whether FEC is applied to all
subflows or each of the subflows individually.  When FEC is applied
to all the flows, there is a risk for the coding rate to be
inadequate for the characteristics of the individual paths.
Draft: draft-irtf-nwcrg-coding-and-congestion-04

Commentary: 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 ( A1 ) . " On the joint use of TCP and Network Coding " ,   , IETF'100 NWCRG session , November 2017 . 
 Since this is IPR protected content I gather the IPR declaration is up to date ? 
 Yes Le mer . 28 oct . 2020 à 10:40 , patibulon écrit : 
 done in PR
In this case, the coding scheme may hide congestion losses from the
congestion controller.  There are cases where this can drastically
reduce the goodput of non-coded flows.  Depending on the congestion
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
flows (see subsec:cc-recov-inter-below).
In this case, the coding scheme may hide congestion losses from the
congestion controller.  There are cases where this can drastically
reduce the goodput of non-coded flows.  Depending on the congestion
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
flows (see subsec:cc-recov-inter-below and TENTET).
The congestion control may not know what is going on in the network
underneath and whether a coding scheme is introduced or not.  The
congestion control may behave as if no coding scheme is introduced.
The only way for a coding channel to indicate that symbols have been
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
occurred), by using ECN signaling.
The congestion control may not know what is going on in the network
underneath and whether a coding scheme is introduced or not.  The
congestion control may behave as if no coding scheme is introduced.
The only way for a coding channel to indicate that symbols have been
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
occurred), by using ECN signaling TENTET.
Draft: draft-irtf-nwcrg-coding-and-congestion-04

Commentary: 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 . 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
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.
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.
The discussion provided in this document aim at encouraging the
research community to also consider congestion control aspects when
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,
especially loss-based congestion control such as CUBIC.
The discussion provided in this document aim at encouraging the
research community to also consider congestion control aspects when
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,
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.
Draft: draft-irtf-nwcrg-coding-and-congestion-02

Commentary: I propose some rewording and talk about sender and receiver instead of server and client . The sender is not always the server and it could be confusing to assume the sender as being a server ( e.g. in ssh it is the inverse ) . Let me know if you disagree on this . 
  contraire , I disliked the client - server thing from the beginning and thought we should move it to sender - receiver some day ! So thanks a LOT for doing this ! 
 LGTM , thanks for this !
There are cases where deploying FEC coding improves the quality of
the transmission.  As an example, when a server transmits data to a
client, it may take time for the server to detect tail losses (i.e.
tail loss can refer to losses at the tail end of transactions).  This
would impact the experience of applications using short flows.
Another example are networks where non-congestion losses are
persistent and prevent a sender from exploiting the link capacity.
There are cases where deploying FEC coding improves the quality of
the transmission.  As an example, it may take time for the sender to
detect tail losses (i.e. tail loss can refer to losses at the tail
end of transactions).  This would impact the experience of
applications using short flows.  Another example are networks where
non-congestion losses are persistent and prevent a sender from
exploiting the link capacity.
fig:sep-channel presents the notations that will be used in this
document and introduce the Congestion Control (CC) and Forward
Erasure Correction (FEC) channels.  The Congestion Control channel
carries source packets (from a server to a client) and potential
information signaling the packets that have been received (from the
client to the server).  The Forward Erasure Correction channel
carries repair packets (from the server to the client) and a
potential information signaling the packets that have been repaired
(from the client to the server).  It is worth pointing out that there
are cases where these channels are not separated.
fig:sep-channel presents the notations that will be used in this
document and introduce the Congestion Control (CC) and Forward
Erasure Correction (FEC) channels.  The Congestion Control channel
carries source packets (from a sender to a receiver) and potential
information signaling the packets that have been received (from the
receiver to the sender).  The Forward Erasure Correction channel
carries repair packets (from the sender to the receiver) and a
potential information signaling the packets that have been repaired
(from the receiver to the sender).  It is worth pointing out that
there are cases where these channels are not separated.
'signaling about losses and/or repaired packets' (input control
plane for the FEC): refers to the information a FEC server can
obtain from a FEC client about the performance of the FEC solution
as seen from the client.
'signaling about losses and/or repaired packets' (input control
plane for the FEC): refers to the information a FEC sender can
obtain from a FEC receiver about the performance of the FEC
solution as seen from the receiver.