Subject: [Fecframe] TSV-DIR review of draft-ietf-fecframe-framework-10

From: Marshall Eubanks <[email-masked]>
Date: Thu, 23 Sep 2010 10:56:20 -0400

I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC [email-masked] if you reply to or forward this review.

I apologize for being late with this, but there is an important transport issue in this document that I think needs to be discussed. 

I should say first that I was part of the design team meetings that lead to this document, and co-chaired the WG during part of its development, but what follows is entirely my opinion. 

This document sets up the overall framework for using Forward Erasure Correction (FEC) in a standards based fashion.

The only real transport issue with the FECFRAME work in general, and this document in particular, is related to Congestion  Control and is described well in Section 8 of the current document, which includes both an "Informative Note" (offset from the main text) and Normative Requirements (in Section 8.1).

FEC does have to deal with congestion control. The intended use of the FEC framework is to protect (i.e., provide redundancy for) arbitrary flows over unreliable transport. That unreliable transport at present is predominately UDP, which does not include congestion control. In practice, FEC can be applied in the middle of the network (say, at the border of a wireless domain), can be applied multiple times, etc. There is also typically no constraint on the amount of FEC applied _from the FEC protocols_ (i.e., the FEC could in principle be many times the bandwidth of the original flow). If the FEC bandwidth was not limited it would, as a worst case, make possible a "tcp fairness attack," where the original flow was limited to some tcp fairness bandwidth, but an arbitrary bandwidth was obtained through a sufficient number of FEC packets. That may not be likely, but FEC in practice may be adaptive (i.e., the FEC bandwidth can be increased or decreased in response to network conditions), and that definitely carries a danger of true congestive collapse (where the FEC bandwidth increases without bound as more packets are lost).

So, it was pretty clear to everyone that some sort of congestion control would be required for the FEC framework. 
There was a solid consensus that FEC should be limited to some proportion of the underlying flow, so the question then becomes, what is the maximum percentage for FEC flows? There were lengthy discussions about this. 
There were proposals that this be limited to the 5% allowed to RTCP (maybe with a RFC 3556 type extension), but this seemed too restrictive (in any wireless network with RFI, for example, 5% would likely be too low). The argument was made (and gained consensus) that the important feature is that the FEC packet flows be limited to some proportion of the underlying flow (and thus adapt based on whatever congestion control is applied to the underlying flow) and that it MUST not be allowed to grow without bound, but that on that basis a fairly large percentage should be OK. So, the adopted text is (Section 8.1) :

     The bandwidth of FEC Repair packet flows MUST NOT exceed the bandwidth of the source packet flows being 
     protected.

This allows for a doubling of the underlying transport bandwidth, but not an unlimited increase in bandwidth. There was consensus that this would allow for almost any realistic FEC scenario, as really high packet loss scenarios tend to at least create problems with signaling of flows and are likely to be simply unusable for real time media transport. 

So, the FEC framework allows for a potential doubling of UDP bandwidth, but no more, and relies on the the underlying application for congestion control. At any rate, I do not think it will cause congestive collapse, as there is no mechanism that allows for bandwidth to grow without bound as network conditions worsen. I think that that is adequate and recommend that this document be approved. 

Regards
Marshall Eubanks