Forward Error Correction (FEC) Framework
draft-ietf-fecframe-framework-15

[Ballot discuss] updated for -14- The new revision has added significantly improved operations and management considerations and security consdierations. I think the text is still ...

[Ballot discuss]
updated for -14-

The new revision has added significantly improved operations and management considerations and security consdierations.
I think the text is still lacking a bit, and the fix should be fairly easy.

1) In the operations and management consideration section, it says:
  In particular, this section discusses the questions of
  interoperability across vendors/use cases and whether defining
  mandatory to implement (but not mandatory to use) solutions is
  beneficial.

The section however fails to discuss interoperability across vendors at all (teh term interoperability is only in the above text).
A paragraph should be added explaining how interoperability of management across vendors will be achieved, at least when the framework is used in the Internet..

2) The Security Considerations says:
  The goals of this section are to state the
  problem, discuss the risks and identify solutions when feasible.  It
  also defines a mandatory to implement (but not mandatory to use)
  security scheme.
IPsec appears to be the baseline security, but the language surrounding IPsec is not specified in RFC2119 langauge that would make this mandatory to implement. Please specify the mandatory to implement security scheme in RFC2119 REQUIRED/MUST language.

[Ballot discuss] Updated based on -11 to -14. 1) addressed. 2) addressed. 3) In Sec 9 penultimate paragraph, the paragraph should be reworked: - if integrity ...

[Ballot discuss]
Updated based on -11 to -14.

1) addressed.

2) addressed.

3) In Sec 9 penultimate paragraph, the paragraph should be reworked:
    - if integrity protection is required, using it above
      FECFRAME, at the ADU level, is operational since all
      corrupted ADUs are finally detected as such. But of
      course there are limits (e.g. DoS as already
      explained).
    - if integrity protection is required, using it below
      FECFRAME has the advantage of reducing DoS risks.
      This is therefore RECOMMENDED.
    - however when applied below FECFRAME, this integrity
      service will not necessarily be end-to-end (depends
      on how FECFRAME is used, end-to-end or not). Whether
      it's appropriate or not depends on whether one can
      tell where the security threats are (which is
      use-case dependent).

4) addressed.

5) addressed.

6) addressed.

TSVDIR Review: I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were ...

TSVDIR Review:

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 tsv-dir@ietf.org 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

[Ballot discuss] I would like to raise the issue raised by Adrian to a DISCUSS - such a document is expected to include information about operational ...

[Ballot discuss]
I would like to raise the issue raised by Adrian to a DISCUSS - such a document is expected to include information about operational impact and manageability of devices and networks that will compy to the framework, also indication about what kind of operations and manageability information future specifications of protocols that comply to the framwork would include. This document includes no such information. I would like to discuss this in the call, maybe these issues are covered in other fecframe documents, or future work planned by the WG.

[Ballot discuss] Section 8 states: We propose a third approach, which is to require at a minimum that the use of this framework with any ...

[Ballot discuss]
Section 8 states:

      We propose a third approach, which is to require at a minimum that
      the use of this framework with any given application, in any given
      environment, does not cause congestion issues which the
      application alone would not itself cause...

Yet a subsequent paragraph states:

      One of the constraints effectively limits the bandwidth for the
      FEC protected packet stream to be no more than roughly twice as
      high as the original, non-FEC protected packet stream.

How can a FEC-protected packet stream not cause congestion issues if it uses twice as much bandwidth as the non-FEC-protected packet stream?

[Ballot comment] Please consider comments from the Gen-ART Review by Joel Halpern on 19-Sep-2010: The text in section 8 seems to imply that cellular devices ...

[Ballot comment]
Please consider comments from the Gen-ART Review by Joel Halpern on
  19-Sep-2010:

  The text in section 8 seems to imply that cellular devices experience
  high loss rates.  This is misleading, as radio protocols generally
  provide sufficient flow control and retransmission so as to bring the
  link behavior to levels similar to that of other media.  Please either
  recheck the assumptions being made, or consider removing the reference
  to cellular links.
 
  The definition of Application Data Unit should include an indication
  that this is referred to as an ADU.

[Ballot comment] Please consider comments from the Gen-ART Review by Joel Halpern on 19-Sep-2010: The text in section 8 seems to imply that cellular devices ...

[Ballot comment]
Please consider comments from the Gen-ART Review by Joel Halpern on
  19-Sep-2010:

  The text in section 8 seems to imply that cellular devices experience
  high loss rates.  This is misleading, as radio protocols generally
  provide sufficient flow control and retransmission so as to bring the
  link behavior to levels similar to that of other media.  Please either
  recheck the assumptions being made, or consider removing the reference
  to cellular links.
 
  The definition of Application Data Unit should include an indication
  that this is referred to as an ADU.

[Ballot discuss] I have only one issue I would like to discuss before recommending approval of this document: Section 5.6 says: 3. The name ...

[Ballot discuss]
I have only one issue I would like to discuss before recommending approval of this document:

Section 5.6 says:

  3.  The name, type, semantics and text value encoding rules for zero
      or more FEC Scheme-specific FEC Framework Configuration
      Information elements.  Names must conform to the "name"
      production and values encodings to the "value" production defined
      in Section 5.5

I am looking at section 5.5 and not seeing any definitions of "name" and "value" there. If you intended to point to
ABNF in [I-D.ietf-fecframe-sdp-elements] then it would be better to have a direct reference.

But anyway, maybe the text in 5.5 referenced in 4.6 is:

  FEC Scheme-specific information elements MAY be encoded into a text
  string for transport within Content Delivery Protocols.  See Section
  4.5 of [I-D.ietf-fecframe-sdp-elements] for the ABNF [RFC5234]
  syntax.

But this would at least mean that [I-D.ietf-fecframe-sdp-elements] needs to be a Normative reference.

[Ballot comment] The term "ADU" is not defined until Page 9, but is used many times before this point in the document. It would assist ...

[Ballot comment]
The term "ADU" is not defined until Page 9, but is used many times before this point in the document. It would assist the reader if it were defined earlier in the document.

Mark, can you post a revised framework doc, without the abnf that has been moved to the sdp doc, so I can send it to ...

Mark,

can you post a revised framework doc, without the abnf that has been moved to the sdp doc, so I can send it to IESG?

IANA understands that in the Reliable Multicast Transport (RMT) FEC Encoding IDs and FEC Instance IDs registry located at: http://www.iana.org/assignments/rmt-fec-parameters ...

IANA understands that in the Reliable Multicast Transport (RMT) FEC Encoding IDs and FEC Instance IDs registry located at:

http://www.iana.org/assignments/rmt-fec-parameters

a new subregistry is to be created.

Registry name: FEC Encoding IDs
Reference: <the approved="" document="">
Registration Procedures: IETF Consensus
Note: The values that can be assigned within the FEC Encoding ID
registry are numeric indexes in the range 0 to 255 inclusive. New
registrations in this subregistry must meet explicit requirements that
are established in <the approved="" document="">.

There are no initial registrations in the new FEC Encoding IDs subregistry.

IANA understands that this is the only action required upon approval of
this document.