Subject: [Fecframe] request for pub draft-ietf-rtp-raptor-04

From: Greg Shepherd <[email-masked]>
Date: Fri, 11 Mar 2011 04:13:28 -0800

*,

The document draft-ietf-fecframe-rtp-raptor-04 is now ready for
publication. Please see the Document Shepherd Write-up below.

Thanks,
Greg

---

Document Shepherd Write-up for draft-ietf-rtp-raptor-04 as per RFC
4858, template dated September 17, 2008

(1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

I, Greg Shepherd as the document shepherd have personally reviewed
this document and believe it to be ready for forwarding to the IESG.

(1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed?

The document has had adequate review both from within and from outside
the FECFrame working group.

(1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

There are no concerns regarding the need for additional expanded review.

(1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

There are no specific concerns with this document.

(1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

There is solid WG consensus for this document.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

There is no discontent.

(1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

Only two miscellaneous warnings  and one outdated reference which can
be addressed with editor's notes:

  == The copyright year in the IETF Trust and authors Copyright Line does not
     match the current year

  -- The document date (November 25, 2010) is 46 days in the past.  Is this
     intentional?

  == Outdated reference: A later version (-04) exists of
     draft-ietf-fecframe-raptor-02

(1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state? If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

Normative and informative references are split with two reference to
drafts that are currently in the editor's queue or will be soon.

(1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

Section 12 describes the IANA considerations, which refers to Section
5 for a comprehensive registration description. The document itself is
primarily a document of media registrations/definitions.

(1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

The xml code validates correctly

(1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

Technical Summary
	This document specifies an RTP payload format for Forward Error
Correction /  (FEC) repair data produced by the Raptor FEC schemes.
Raptor FEC schemes are specified for use with the IETF FEC Framework
which supports transport of repair data over both UDP and RTP. This
document specifies the payload format which is required for the use of
RTP to carry Raptor repair flows.

Working Group Summary
	There were no seriously contentious issues during the WG process.

Document Quality
	The Working Group feedback covered both the quality of the document
itself as well as the technical issues with the content of the
document.

Personal
	Document Shepherd - Greg Shepherd
	Responsible Area Director - David Harrington <[email-masked]>

---

From: Vincent Roca <[email-masked]>
Date: Fri, 18 Mar 2011 15:18:27 +0100

Greg, Mike, everybody,

We had a discussion last month on the topic:
         "Managing losses between the sending application
          and the FECFRAME instance"
as part of the framework I-D (see the bottom of page 41 for
the agreed text).

The RTP Raptor I-D is of course concerned by this discussion
and unfortunately this -04 version is from November 2010,
before the discussion.

Unless I missed some key sentence, I have the feeling that this
I-D implicitly assumes there CANNOT be any RTP packet loss
before reaching the Fecframe encoder, i.e. the RTP SN are always
in sequence.

(NB: the only text I've found that discusses RTP SN is in
section 3 and does not mention this requirement at all)

It's a critical requirement that MUST be clearly stated. If there is
any risk this requirement does not hold, the I-D MUST define an
appropriate behavior. So it's worth a quick fix (it's fairly easy) IMHO.
Note that it might also be an attack (in specific deployment
scenarios, not all of them of course), so it's also worth saying a
few words in section 12 as well (BTW, we should do the same in
the FEC Framework I-D, I didn't realize that before, sorry).

Cheers,

   Vincent

On 11/03/11 13:13, Greg Shepherd wrote:
> 	Responsible Area Director - David Harrington<[email-masked]>
> _______________________________________________
> Fecframe mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/fecframe

---

From: "Luby, Michael" <[email-masked]>
Date: Mon, 21 Mar 2011 15:40:59 -0700

Hi Vincent,
Some comments inline.
Best, Mike

> before reaching the Fecframe encoder, i.e. the RTP SN are always
*** Yes, makes sense.
> the FEC Framework I-D, I didn't realize that before, sorry).

*** There seems to be a couple of ways to solve this.  One, as you suggest,
is to mandate that the solution must have all source packets arrive at the
FEC encoder.  Another way is to have logic at the FEC encoder that detects
if there are missing packets (easy to do in this case because of the RTP
sequence numbers), and if so, for FEC encoding purposes (not transmission
purposes), creates a dummy packet of all zeroes for each missing sequence
number (or whatever the receiver is going to interpret as a valid packet but
with no real audio/video info inside), and encode the source block including
the dummy packet(s).  Probably best to point out the problem and then
mention some possible ways to solve it.

*** It should be noted that in any system where not all the source packets
containing video/audio data get to the FEC encoder is pretty badly designed,
as no matter how you overcome it, you are still going to be missing
video/audio at all the clients that receive the stream.  At least if you
have RTP sequence numbers in the source packets you will know this at the
FEC encoder (may not be true of other solutions, i.e., it may even be hard
to detect that not all the video/audio source packets get to the FEC
encoder, and this probably should be pointed out for other solutions).

---

From: Vincent Roca <[email-masked]>
Date: Wed, 23 Mar 2011 09:44:31 +0100

Hello Mike,

> mention some possible ways to solve it.

I agree, let's point the issue first and then suggest a few ways to fix
or mitigate it. Which solution to prefer depends on the use-case.
This is already discussed in version -14 of the framework I-D
(section 10.2):
---
       In this case,
       another solution SHOULD be considered that is use-case specific
       and whose consequences need to be carefully considered (e.g., by
       duplicating the last ADU received before the loss, or by inserting
       a zero'ed ADU, depending on the ADU flow nature).
---

However inserting a dummy source packet and not sending it
means it will be considered as erased at the FECFRAME decoding,
which impacts the recovery capabilities of the FEC scheme.
And we have no way to signal to the receiver this is a dummy
source packet.

So there are two good reasons such erasures do not happen
too often:
1) because a missing audio/video source packet impacts the
     perceived quality,
2) because it also impacts the FEC protection of source packets
     that are considered by the FECFRAME encoder.

An alternative is of course to send such dummy source packets
of signal them to the receiver (not feasible with current specs).

> encoder, and this probably should be pointed out for other solutions).
Good point. However I guess there are other means to identify
missing ADUs within the upper application, even if it's not
visible at FECFRAME level.

Cheers,

   Vincent

---

From: "Luby, Michael" <[email-masked]>
Date: Wed, 23 Mar 2011 10:57:28 -0700

Comments below.
Cheers, Mike

> of signal them to the receiver (not feasible with current specs).
*** There is no benefit of sending the dummy source packets that I can see,
as they don't contain any information that can help the receiver.  The rest
seems ok.
> visible at FECFRAME level.
*** Not always true.   For example, using MPEG2-TS format (pretty typical
for broadcasters where this technology might be deployed) doesn't have any
real easy to extract a unique packet identifier at the FEC sender to verify
that there isn't any packet loss, and thus at the very least there would
have to be a pretty deep packet inspection at the FEC sender to determine if
there are missing source packets.