Subject: [AVT] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-03

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sat, 18 Apr 2009 14:03:36 -0700

This update addresses all the comments received in the WGLC period initated on April 1st. If there are further comments, please post them soon as we would like to move forward with this draft.
http://www.ietf.org/internet-drafts/draft-ietf-fecframe-interleaved-fec-scheme-03.txt

BR,
-acbegen 

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]] 
Sent: Saturday, April 18, 2009 1:58 PM
To: Ali C. Begen (abegen)
Subject: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-03 

A new version of I-D, draft-ietf-fecframe-interleaved-fec-scheme-03.txt has been successfuly submitted by Ali Begen and posted to the IETF repository.

Filename:	 draft-ietf-fecframe-interleaved-fec-scheme
Revision:	 03
Title:		 RTP Payload Format for 1-D Interleaved Parity FEC
Creation_date:	 2009-04-18
WG ID:		 fecframe
Number_of_pages: 31

Abstract:
This document defines a new RTP payload format for the Forward Error
Correction (FEC) that is generated by the 1-D interleaved parity code
from a source media encapsulated in RTP.  The 1-D interleaved parity
code is a systematic code, where a number of repair symbols are
generated from a set of source symbols and sent in a repair flow
separate from the source flow that carries the source symbols.  The
1-D interleaved parity code offers a good protection against bursty
packet losses at a cost of decent complexity.  The new payload format
defined in this document is used (with some exceptions) as a part of
the DVB Application-layer FEC specification.

The IETF Secretariat.

---

From: "Roni Even" <[email-masked]>
Date: Fri, 24 Apr 2009 17:30:29 +0300

Hi,
I am sorry that I did not review the draft before since I am not subscribed
to fecframe and AVT was not cc'ed on the WGLC.

I have some editorial comments:

1. In section 1 you reference RFC2733, I think it was obsolete by RFC 5109 ,
do you need this downref?

2. In the registration section 5.1, the comments applies to all subtypes:  
  2.1  You have for security considerations and published specification
"this document" it is better to write RFC xxxx and have a note to     	the
RFC editor to replace it with the RFC number allocated, this will show in
the IANA registry with the write pointer.

  2.2 In the restriction on usage I assume that the document is using RTP
framing and is not specified for other types, if this is the 	case it
should say so. E.g. "   This media type depends on RTP framing, and hence is
only defined for transfer via RTP [RFC3550].  	Transport within other
framing  protocols is not defined at this time"
  2.3 You need to add the "additional information" that is in the template
probably saying none

3. In section 5.2.1 it looks like you require symmetry between the send and
received stream. Is this your requirement. 

4. In section 5.2.1 can the answerer send a response with no FEC at all even
if not offered.

5. In section 5.2.2 Can the receiver just ignore the fec stream, the text
has a MUST use the configuration that is offered which can hint that it MUST
use FEC.

6. In section 7 you discuss an exchange using grouping. Is it also allowed
to use FEC withoutout grouping using the video or audio media types like
section 14 in RFC 5109

Thanks
Roni Even

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ali C.
Begen (abegen)
Sent: Sunday, April 19, 2009 12:04 AM
To: [email-masked]
Cc: [email-masked]
Subject: [AVT] FW: New Version Notification for
draft-ietf-fecframe-interleaved-fec-scheme-03

This update addresses all the comments received in the WGLC period initated
on April 1st. If there are further comments, please post them soon as we
would like to move forward with this draft.
http://www.ietf.org/internet-drafts/draft-ietf-fecframe-interleaved-fec-sche
me-03.txt

BR,
-acbegen 

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]] 
Sent: Saturday, April 18, 2009 1:58 PM
To: Ali C. Begen (abegen)
Subject: New Version Notification for
draft-ietf-fecframe-interleaved-fec-scheme-03 

A new version of I-D, draft-ietf-fecframe-interleaved-fec-scheme-03.txt has
been successfuly submitted by Ali Begen and posted to the IETF repository.

Abstract:

The IETF Secretariat.

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 24 Apr 2009 09:52:02 -0700

Thanks for the review. See inline. 

> do you need this downref?

Yes, this has been already discussed within fecframe and with Magnus. We give an informative reference as we are using an extension of the header RFC 2733 had.
 
> the IANA registry with the write pointer.

Will do.
 
> framing  protocols is not defined at this time"

Will do.

>   2.3 You need to add the "additional information" that is in 

I believe I already have "additional information: none" for each subtype.

> received stream. Is this your requirement. 

I am not sure what "symmetry" means here. Could you explain?
 
> 4. In section 5.2.1 can the answerer send a response with no 

If the answerer does not want FEC, yes, it can drop FEC from the offer. Let me make that clear in the text.

> has a MUST use the configuration that is offered which can 

The receiver may decide to receive or not receive the FEC stream. If it decides to receive, it MUST use the configuration that is provided for the session. I guess the text is clear about this point.

> to use FEC withoutout grouping using the video or audio media 

Per FEC framework, we require the FEC to be in a separate flow, which requires the source and FEC streams to be on different RTP sessions. Thus, we require grouping (RFC 4756 or 4756bis)

BR,
-acbegen
 
> A new version of I-D, 
> draft-ietf-fecframe-interleaved-fec-scheme-03.txt has

---

From: "Roni Even" <[email-masked]>
Date: Fri, 24 Apr 2009 22:03:13 +0300

Ali,
Inline
Roni

RE- The order was different so I missed it

RE - Symmetry means that the offerer and answerer MUST use the same mode
since this exchange results in a two streams, one from each direction.

> has a MUST use the configuration that is offered which can 

The receiver may decide to receive or not receive the FEC stream. If it
decides to receive, it MUST use the configuration that is provided for the
session. I guess the text is clear about this point.

RE- I think it has to do with my assumption that you can multiplex the
streams like RFC 5109

> to use FEC withoutout grouping using the video or audio media 

Per FEC framework, we require the FEC to be in a separate flow, which
requires the source and FEC streams to be on different RTP sessions. Thus,
we require grouping (RFC 4756 or 4756bis)

RE- I will have to look at that draft, this is different from RFC 5109 and
RFC 2733

BR,
-acbegen

---

From: "Roni Even" <[email-masked]>
Date: Fri, 24 Apr 2009 22:31:39 +0300

Ali,
I am a bit confused about your answer, I assume that FEC framework you refer
to draft-ietf-fecframe-framework-03, at least I cold not see any reference
in the draft to a document. 
In section 4 of the above draft it says 

"
In the case that RTP is used for the repair flows, the source and repair
   data may be multiplexed using RTP onto a single UDP flow and must
   consequently be demultiplexed at the receiver."

Roni

In the case that RTP is used for the repair flows, the source and repair
   data may be multiplexed using RTP onto a single UDP flow and must
   consequently be demultiplexed at the receiver.

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 24 Apr 2009 12:38:34 -0700

> RE- I will have to look at that draft, this is different from 

Actually, we might be supporting SSRC multiplexing in the fec framework (see my email sent today to fecframe/mmusic about this topic), since there are some use cases for it. It does bring up other issues, though. I would be glad to hear your comments.

There are also some issues with RFC 5109 regarding SSRC multiplexing as you mentioned in one of your earlier emails that may need to be addressed.

BR,
-acbegen

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 24 Apr 2009 12:46:40 -0700

Yes, that is the fecframework draft, and I raised exactly the same point this morning in the fecframe/mmusic list when I noticed that text in the draft. Please use that thread for that discussion. 

-acbegen

> From: Roni Even [mailto:[email-masked]] 
> Sent: Friday, April 24, 2009 12:32 PM
> To: Ali C. Begen (abegen); [email-masked]
> Cc: [email-masked]
> Subject: RE: [AVT] FW: New Version Notification for