Change:
'coding rate' (output control plane for the FEC): refers to the coding rate that is used by the FEC solution. <del> 'source and/or repair packets' (data plane for both the FEC and the CC): refers to the packets that are transmitted.  There can only be source packets (if the coding rate is 0), repair packets (if the solution decides not to send the original source packets) or a mix of both. </del> <ins> 'source and/or repair symbols' (data plane for both the FEC and the CC): refers to the data that is transmitted.  The sender can decide to send source symbols only (meaning that the coding rate is 0), repair symbols only (if the solution decides not to send the original source packets) or a mix of both. </ins> The inputs to FEC (packets to work upon, and signaling from the <del> receiver about losses and/or repaired packets) are distinct from the </del> <ins> receiver about losses and/or repaired symbols) are distinct from the </ins> inputs to CC.  The latter calculates a sending rate or window from network information, and it takes the packet to send as input, sometimes along with application requirements such as upper/lower

Discussion:
My 2 cents and it’s probably not worth more: I am following the evolution of this draft and while the issues are starting to be well covered this is RG document so while I approve of the changes it would be nice to highlight the research that is still needed. mjm Marie-José Montpetit, Ph.D. EMAIL
Regarding Marie-José's comment: I agree, and I think that we could approach this by trying to find at least one published example of research per category - ideally the "best" per category. This would show, wherever we find something, what the SoA is - research could focus on improving this SoA. Also, it would probably give us some holes - e.g., I don't think there's any much research on (e2e!) FEC "below the transport", especially using multiple CC instances as hinted on in the draft. These holes would let us identify missing research.
You should define what you mean by fairness. I remember endless discussions about fairness in NC with Bob Briscoe amongst others. Marie-José Montpetit, Ph.D. EMAIL
I have corrected most of the comments and issues. I have added two issues to discuss the discussion points opened by Marie-José. How about we merge this and have a new fresh start ? (from which it will be easier for you to create branches, etc.) I guess, looking at the amount of modifications, NAME : may you merge if OK with you?
Ah sorry, I see the comment now, asking me to merge - ok, then I click these 3 "commit"s and then I merge! Doing it now!
Emmanuel made a comment on partial reliability. Should we need a new subsection 6.X to discuss this ?
I don't get this: Emmanuel's comment was about partial order, not partial reliability. Quote: One important thing to consider is reordering and not only reliability alone, we could also consider Partial Order Connection (POC) and Partial Order Transport Service (see Paul Amer works). Spurious retransmission is not only linked to reliability but reordering.

If this issue ends up being about ordering, and not partial reliability: From francoismichel (copied over from a PR): There is something we do not mention here concerning the reliable transport that deliver data in-order : with a reliable transport, the data are delivered in order. I can see two possible cases: Above a single TCP connection: the repair packets won't ever be delivered to the applications if there is a loss occurring before them. They are thus useless as they are delivered once the loss is receovered. Above multiple streams (e.g. QUIC streams or one TCP connection for the source and one for the repair symbols): the repair symbols are less effective: if there is a hole in the data (ex: seq 1 and 3 are received but not 2),you will need to consider 3 a lost too as it won't be delivered to the upper layer.
An answer from me to this: there are transports that can deliver data out-of-order. SCTP can do that, and it's exposed in the interface of TAPS ( draft-ietf-taps-interface ). Multi-streaming is closely related to that: if you take out-of-order message delivery and just add stream identifiers to ensure that, per stream, messages are delivered in order, you have it. This means that FEC could perhaps be applied across streams in case of a multi-streaming transport. I think this just complicates the discussion, let's not go there in the draft.
Thank you for summing up the discussion here. I think we already quite an important number of new sections in this document - we may leave the topic on out-of-order packets on the side and focus on what we have at the moment.
Ok, but do we agree that this is about "partial ordering", not "partial reliability"? In this case, we should probably rename this issue to avoid further confusion.
Text proposed in PR
Should we consider the impact of cross trafic that uses congestion-controled transport protocol?
done in PR
There should be a discussion on the amount of redundancy of the FEC e.g. FEC above transport : including redundancy reduces goodput for large files transfers e.g. FEC in transport : including redundancy reduces goodput for large files transfers but can be adapted depending on the CWND size e.g.

FEC below transport : including redundancy adds congestions without reducing goodput
From Dave Oran (IETF108): One thing it might be good to cover is how to couple increasing transmission rate with increasing/decreasgin coding rate. It may be interesting to use increasing coding rate as a "probe" to more safely increase transmission rate. Has this been looked at?
Done in PR
More related work, examples of FEC research work? Papers? This kind of thing? (I agree, just clarifying if this is what this issue is asking for)
Started in PR
The title of the document is "Coding and congestion control in transport" but we only present a "FEC Channel" that only carries repair packets and some signaling about the repaired packets. I like the idea of two separated channels a lot, but I think we also should integrate source packets as part of the FEC channel, and maybe rename the FEC channel to "Coding Channel" and "packets" to "symbols" when we talk about the coding channel ? Here is what I propose concretely: The CC channel stays unchanged, it carries packets The FEC channel becomes a Coding channel and carries symbols: Source Symbols and Repair Symbols. I think the approach there is more general: one network packet can contain several Source/Repair Symbols (similarly to the coding-for-quic draft). I think this helps to isolate both CC and FEC channels from each others as the FEC/Coding channel only plays with Symbols while the CC channel plays with packets. When I read the current design, it makes me think that the FEC channel needs the source packets from the CC channel to decode the received repair packets but this is shown nowhere in the graph. By considering different entities (packets VS symbols that are in fact a view on the sent/received data), we decorrelate more intuitively the FEC and the CC channels. As a consequence, we will only talk about symbols when it concerns the Coding channel and packets when it concerns the CC channel. What do you think ? I do not think this is an urging change by the way.
Hi, Coding channel refers to physical layer and when combined with the term symbol, it also refers to physical operations which are not those at packet level.

We stated in RFC8406 that Generally speaking, a Packet is the unit of data that is sent in the Packet Erasure Channel, while a Symbol is the unit of data that is manipulated during the encoding and decoding operations. So we allow the use of symbol only when it corresponds to non yet transmitted data. As soon as transmitted, it becomes a packet. EL
Hello, symbol, it also refers to physical operations which are not those at packet level. Hmm, in that case, renaming the channel this way would make it more confusing I agree, sorry for that then :-) transmitted data. As soon as transmitted, it becomes a packet. I think the definition I proposed here still fits with the symbol definition you described though. A packet can contain more than 1 source/repair symbol(s) and the source symbols can be different than what is actually sent on the wire (e.g. source symbols can contain padding that is not actually sent on the wire or can contain metadata that are not sent on the wire either). So I still think that it matches more the definition of symbols than packets. All the real packets received by a protocol can be processed and transformed into source symbols before being passed to the FEC Channel. (sorry in advance if I have misconceptions on this matter)
Yes in that context it's fine and we stick to RFC8406.
Done in PR
DO: Fine, but you miss the opposite case: how many repair packets are you sending that turn out to be useless? It's a matter of measuring the usefulness of repair traffic. It gives an extra degree of freedom as you may want to play at the congestion control level or at the coding rate level. NK: Good point, that's the kind of topic we need to gather in the document. There are several corner cases that are very important. This point is about how you add coding inside congestion control. With this claim, we want to be generic.
I think this document ought to remove the confusion between coding and congestion control that folks seem to have. So: "It gives an extra degree of freedom as you may want to play at the congestion control level or at the coding rate level." sounds like it's based on this confusion. And: "This point is about how you add coding inside congestion control." doesn't seem right either.

Indeed - the introduction of the coding and congestion channels could help. I may need to be reflected in the rest of the document.
Maybe we could emphasize on the fact that coding is a reliability mechanism and is distinct and separated from the loss detection and congestion control mechanisms. If all we care about is bandwidth in a general unicast scenario, sending a-priori repair packets should not help more than Selective-Repeat ARQ. In the best case, it should perform as well as a SR-ARQ if the packet is lost (without additional gain), and will simply waste bandwidth compared to SR-ARQ if the packet is not lost. I can identify one case where doing FEC can help for bandwidth: when the buffer are full or very limited and cannot be in-order delivered to the application because of head-of-line blocking. Sending FEC could help to unblock the peer's receive buffer sooner. But this has nothing to do with congestion control.
I think this kind of discussion should be in the document.
I agree with NAME 's idea of unblocking the receiver. Also, in the other issue, he mentioned the big disadvantage (delay) coming from tail losses. These things should now be added to the document - now it's structured such that it could be added better, in the right place. Other thoughts that were brought up in discussions, and should go into the doc - both are about the FEC-below-transport case: 1) ECN: From NAME : There is more detail about possibilities to use ECN for FEC-below-transport in Emmanuel's presentation: URL (slide 4) 2) special environments: and we had this discussion in a PR related to FEC-below-transport: NAME wrote: and I answered: .... and about the FEC-above-transport case slide 2 reminds me that this is obviously useless if the transport repairs all losses, as with TCP! This is worth mentioning in the FEC-above-transport case - we could mention that unreliable congestion-controlled transports (e.g. RMCAT cc's, or DCCP) are better to consider here than fully reliable ones such as TCP.
I am unsure where this issue is going and what we can integrate in the draft then.

I would say that identifying useless repair packets is the work of the reliability mechanism (there is a clear similarity with spurious retransmissions detection) and in my opinion has nothing to do with congestion control, so what can we integrate in the draft ?
I think this discussion is covered in PR
Thanks for the PR ! :-)There are two small suggestions that I made... not sure they're committed yet? Else just press "commit" 3 times please :)