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

From: Colin Perkins <[email-masked]>
Date: Fri, 1 May 2009 10:27:24 +0100

On 1 May 2009, at 07:56, Roni Even wrote:
> Hi Ali,
> This is up to the WG to decide if they want to have support for SSRC  
> multiplexing and the implications of this support. I am not sure  
> what you mean by "we cannot have a parameter", I see only your view  
> on the list.

The grouping mechanism would seem to be sufficient. Why do we need a  
special-purpose mechanism, when we can reuse a general approach?

Colin

> If only session multiplexing is allowed then the draft should  
> clearly state it and in this case I am not sure why you are  
> registering the video, audio and text media subtypes.
>
> Roni
>
> -----Original Message-----
> From: Ali C. Begen (abegen) [mailto:[email-masked]]
> Sent: Friday, May 01, 2009 2:45 AM
> To: Roni Even; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: [AVT] [Fecframe] FW: New Version Notification for draft- 
> ietf-fecframe-interleaved-fec-scheme-04
>
> Hi Roni,
>
> Thanks for the references. However, we cannot have a parameter that  
> will relate the FEC stream to the source as RFC 4588 did with "apt"  
> since a lot of possibilities (multiple sources and/or multiple  
> repair flows) are possible with FEC. Instead, we use grouping and  
> this works just fine in session multiplexing.
>
> Regarding SSRC multiplexing of source and FEC streams, I don't think  
> giving an explicit example is needed or it is a good idea for this  
> draft since SSRC-level grouping is just introduced in 4756bis and it  
> will include such examples anyway (actually the version I submitted  
> today includes an example). We should better only provide session  
> multiplexing examples in this draft. This also emphasizes the  
> recommended way of doing FEC.
>
> Reg the registration of the media types and SDP mappings, I believe  
> the draft has the necessary details.
>
> BR,
> -acbegen
>
>> -----Original Message-----
>> From: Roni Even [mailto:[email-masked]]
>> Sent: Thursday, April 30, 2009 1:03 PM
>> To: Ali C. Begen (abegen); [email-masked]
>> Cc: [email-masked]; [email-masked]
>> Subject: RE: [AVT] [Fecframe] FW: New Version Notification
>> for draft-ietf-fecframe-interleaved-fec-scheme-04
>>
>> Ali,
>> You can find examples in section 8.6 to 8.8 of RFC 4588,
>> notice that there is an optional parameter for the rtx stream
>> that defines the relation between the original and the rtx
>> stream. Similar solution is also specified for redundant
>> encoding red payload type (RFC 2198). You are offering both
>> streams with different payload type numbers in the same m-line.
>> In this case the media type must be video or audio same as
>> the media type of the protected stream. This is why you
>> needed the registration for type audio and video
>>
>> Roni
>>
>> -----Original Message-----
>> From: Ali C. Begen (abegen) [mailto:[email-masked]]
>> Sent: Thursday, April 30, 2009 10:01 PM
>> To: Roni Even; [email-masked]
>> Cc: [email-masked]; [email-masked]
>> Subject: RE: [AVT] [Fecframe] FW: New Version Notification
>> for draft-ietf-fecframe-interleaved-fec-scheme-04
>>
>> Hi Roni,
>>
>>> I noticed that the fec framework will allow SSRC
>>
>> Yes, it will not be the recommended way of using FEC, but it
>> will be supported. The 4756bis draft also supports it now.
>>
>>> multiplexing, are you going to specify this in this draft in
>>> the SDP offer answer section.
>>
>> I am not sure what I need to specify additionally in this
>> section regarding SSRC multiplexing. Could you let me know if
>> there is such an example?
>>
>>> Maybe you should also discuss when to use application media
>>> type and when to use video or audio
>>
>> I believe the FEC is always application type, we did
>> registration for video, audio, etc. since FEC could relate to
>> sessions carrying such types.
>>
>> BR,
>> -acbegen
>>
>>>
>>>
>>> Roni
>>>
>>>
>>>
>>> From: [email-masked] [mailto:[email-masked]] On
>>> Behalf Of Ali C. Begen (abegen)
>>> Sent: Thursday, April 30, 2009 3:54 PM
>>> To: [email-masked]
>>> Cc: [email-masked]; [email-masked]
>>> Subject: Re: [AVT] [Fecframe] FW: New Version Notification
>>> for draft-ietf-fecframe-interleaved-fec-scheme-04
>>>
>>>
>>>
>>> Hi Vincent
>>>
>>> This draft is not an fec scheme so it is not related to fec
>>> framework. It is an rtp payload format draft. The wglc has
>>> been running almost a month now. If you have comments in this
>>> perspective, pls submit them soon.
>>>
>>>
>>>
>>>
>>> -acbegen
>>>
>>> ----- Original Message -----
>>> From: Vincent Roca <[email-masked]>
>>> To: Ali C. Begen (abegen)
>>> Cc: [email-masked] <[email-masked]>; [email-masked]
>> <[email-masked]>
>>> Sent: Thu Apr 30 03:58:35 2009
>>> Subject: Re: [Fecframe] FW: New Version Notification for
>>>  draft-ietf-fecframe-interleaved-fec-scheme-04
>>>
>>> Hello Ali,
>>>
>>> I'm not in favor of finalizing the WGLC for this document.
>>> IMHO we must,
>>> first of all, finalize the framework document itself.
>>>
>>> For instance, the terminology used by the interleaved-fec-scheme I-D
>>> (section 3.1.) is not in line with the terminology used by the
>>> fecframe-framework-03 I-D (Section 2):
>>>        "Source Flow"   vs. "Source data flow"
>>>        "Repair Flow"   vs. "Repair data flow"
>>>        "Source Symbol" vs. nothing
>>>        "Repair Symbol" vs. nothing
>>>        "Source Packet" vs. nothing
>>>        "Repair Packet" vs. nothing
>>> And as I said before, IMHO the terminology proposed in the framework
>>> I-D should be discussed too.
>>>
>>> So let's do things in the right order, especially as the framework
>>> WGLC finishes soon.
>>>
>>> Additionally, I may have some comments for the
>>> interleaved-fec-scheme-04
>>> I-D. Since I missed the WGLC deadline, you have the right to
>>> blame me ;-)
>>> and I apologize in advance.
>>>
>>> Regards,
>>>
>>>  Vincent
>>>
>>>
>>> Ali C. Begen (abegen) wrote:
>>>> This version addresses the comments received from fecframe
>>> and avt so far.
>>>>
>>> http://www.ietf.org/internet-drafts/draft-ietf-fecframe-interl
>> eaved-fec-scheme-04.txt
>>>>
>>>>
>>>> Fecframe chairs,
>>>>
>>>> Could we proceed and finalize WGLC?
>>>>
>>>> -acbegen
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: IETF I-D Submission Tool [mailto:[email-masked]]
>>>> Sent: Wednesday, April 29, 2009 2:56 PM
>>>> To: Ali C. Begen (abegen)
>>>> Subject: New Version Notification for
>>> draft-ietf-fecframe-interleaved-fec-scheme-04
>>>>
>>>>
>>>> A new version of I-D,
>>> draft-ietf-fecframe-interleaved-fec-scheme-04.txt has been
>>> successfuly submitted by Ali Begen and posted to the IETF
>> repository.
>>>>
>>>> Filename:      draft-ietf-fecframe-interleaved-fec-scheme
>>>> Revision:      04
>>>> Title:                 RTP Payload Format for 1-D
>>> Interleaved Parity FEC
>>>> Creation_date:         2009-04-29
>>>> 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.
>>>>
>>>>
>>>> _______________________________________________
>>>> Fecframe mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/fecframe
>>>
>>>
>>
>>
>
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

-- 
Colin Perkins
http://csperkins.org/

---

From: "Roni Even" <[email-masked]>
Date: Fri, 1 May 2009 13:22:18 +0300

Colin,
I am not sure that grouping will work when you have SSRC multiplexing and
both the protected stream and the fec stream are in the same m-line, the mid
attribute is per m-line

Roni

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]] 
Sent: Friday, May 01, 2009 12:27 PM
To: Roni Even
Cc: 'Ali C. Begen (abegen)'; [email-masked]; [email-masked]
Subject: Re: [AVT] [Fecframe] FW: New Version Notification for

Colin

-- 
Colin Perkins
http://csperkins.org/

---

From: "Jonathan Lennox" <[email-masked]>
Date: Fri, 1 May 2009 11:38:07 -0400

The intention is to use ssrc-group (from
draft-ietf-mmusic-source-attributes) for ssrc grouping.

-- 
Jonathan Lennox
Vidyo, Inc
[email-masked]

> Sent: Friday, May 01, 2009 6:22 AM
> To: 'Colin Perkins'
> Subject: Re: [AVT] [Fecframe] FW: New VersionNotification for draft-
> >>> For instance, the terminology used by the interleaved-fec-scheme
I-
> D

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 1 May 2009 09:05:11 -0700

Yes, this has been discussed in mmusic very recently and I updated the 4756bis draft accordingly.

http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc4756bis-02.txt

-acbegen  

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Jonathan Lennox
> Sent: Friday, May 01, 2009 8:38 AM
> To: Roni Even; Colin Perkins
> Subject: Re: [Fecframe] [AVT] FW: NewVersionNotification for 
> > I am not sure that grouping will work when you have SSRC 
> multiplexing
> > and

---

From: "Roni Even" <[email-masked]>
Date: Fri, 1 May 2009 21:07:28 +0300

Jonathan,
Thanks for the reference. I suggest that if ssrc multiplexing is allowed
there should be some text referencing the mmusic-source-attribute draft and
explaining the limitation comparing to the session multiplexing.
Roni Even

-----Original Message-----
From: Jonathan Lennox [mailto:[email-masked]] 
Sent: Friday, May 01, 2009 6:38 PM
To: Roni Even; Colin Perkins
Cc: [email-masked]; [email-masked]
Subject: RE: [AVT] [Fecframe] FW: New VersionNotification for

-- 
Jonathan Lennox
Vidyo, Inc
[email-masked]

I-

---

From: Vincent Roca <[email-masked]>
Date: Mon, 04 May 2009 17:10:30 +0200

Hello Ali,

As promised, here are my comments for your I-D.
And sorry for being rather late.
Regards,

 Vincent
Comments to  draft-ietf-fecframe-interleaved-fec-scheme-04 
Vincent - May 3rd, 2009
----------------------------------------------------------

For discussion...

I- Main comments
----------------

1/** Introduction, p.4
It is said:
  "Note that the sender MUST transmit the source and repair packets in
   different source and repair flows, respectively to offer backward
   compatibility (See Section 4)."
The fact that source an repair packets belong to different flows is
not sufficient to offer backward compatibility, since the notion of
source/repair flow says nothing about the way these flows are
transported in transport flows (see Definition, section 3.1).
This sentence suggests on the contrary that they are transported
independently which is not necessarily the case (cf. last week mailing
list thread).

I suggest:
  "Note that the source and repair packets belong to different source
   and repair flows, and the sender MUST provide a way for the receivers
   to demultiplex them, even in the case they are sent in the same
   transport flow (i.e., same source/destination IP/port with UDP).
   This is required to offer backward compatibility (See Section 4)."

I also suggest to clarify the Source/Repair Flow definitions in
Section 3.1, to say explicitly that there are different possible
mappings to transport flow(s).

2/** Section 4.2, p13:
It is said:
   o  Synchronization Source (SSRC):  The SSRC value SHALL be randomly
      assigned as suggested by [RFC3550].  This allows the sender to
      multiplex the source and repair flows on the same port, or
      multiplex multiple repair flows on a single port. 

I suggest to refer to "transport flows", i.e., in case of UDP, the
5-tuple, rather than "port" which is much more imprecise. BTW, do you
refer to the source or destination port in the above sentence, and
what about the source/destination address?

3/** Fig. 3: 
Current figure looks like the following:
           [...]
             +        
        ------------- 
       |     XOR     |
        ------------- 
              =      
            +===+    
            |C_1|   
            +===+  

I don't like the "+ XOR" in the above figure, since it suggests (to me
at least) that the {S_1 .. S_XXX} symbols are "summed" with a XOR symbol
to produce the C_1. I'd prefer something like:

       XOR sum of set
       +-------------+
       | S_1         |
       | S_L+1       |
       | .           |
       | .           |
       | .           |
       | S_(D-1)xL+1 |
       +-------------+
              =      
            +===+   
            |C_1|  
            +===+ 

(and something similar with the 1D/2D I-D)

4/** Section 4.2 "Repair Packets", p12, RTP header clarifications.
I don't like the sentences:
	"This bit is obtained by applying protection to the corresponding
	XX bits from the RTP headers of the source packets protected by
	this repair packet".

We don't apply any protection to produce this bit, this is the contrary.
I suggest:
	"This bit is equal to the XOR sum of the corresponding XX bits
	from the RTP headers of the source packets protected by this
	repair packet".

5/** Section 4.2, p 15:
It is said (last sentence):
   "Instead, a systematic approach is inherently more efficient."
I don't like the "systematic" adjective above.
I suggest:
    Instead, providing implicitly the list, thanks to the {base
    sequence number; D; L} tuple and the knowledge of the associated
    algorithm, is more efficient."

6/** Section 5.2.1, p21:
It is said:
     "The size of the repair-window is related to how fast the
      sender will send the repair packets."
I don't agree with the wording "how fast". It's more a matter of
delay with the transmission of the repair packet for a given
source packet than a "bandwidth" issue".
I suggest:
     "The size of the repair-window is related to the maximum delay
      between the transmission of a source packet and the associated
      repair packet."

7/** Section 6, p.22:
It is said:
  "This section provides a complete specification of the 1-D interleaved
   parity code."
This is not only a specification of the code, but also of the new RTP
payload format for these codes.

8/** Section 6, p.23:
It is said:
  "Note that if the payload lengths of the source packets are not equal,
   each shorter packet MUST be padded to the length of the longest
   packet by adding octet 0's at the end.  Due to this possible padding
   and mandatory FEC header, a repair packet usually has a larger size
   than the source packets it protects.  This may cause problems if the
   resulting repair packet size exceeds the Maximum Transmission Unit
   (MTU) size of the path over which the repair flow is sent."

Several issues:
 - it's not only a problem of different payload lengths. If two packets
   have the same payload lengths but different variable length lists/
   extensions, then the bit streams will have different length too.
   The first sentence should be corrected.

 - we need to define what "the longest packet" means. Is it for this
   set of source packets (I assume yes) or for all the packets of the
   session (if this has a meaning)?

 - we need to define what "length" means. Is it only the payload length,
   or does it include the various variable length extensions/lists?

 - a repair packet ALWAYS (rather than "usually") has a larger size
   than the source packets it protects (even the longest one, because
   of the additional 16 byte FEC header in that case).

9/** Section 6.3.1, p 25:
The following formula is provided to generate the source packet 
sequence number:
	p*_snb + i * L
This equation should take into account the possible wrapping of this
16-bit RTP sequence number field.
I suggest:
	(p*_snb + i * L) modulo (65536)

10/** Section 6.3.2. "Recovering the RTP Header and Payload", p 25
It is said:
   2.   For the repair packet associated with set T, compute the bit
        string in the same fashion except use the PT recovery field
        instead of the PT field and TS recovery field instead of the
        Timestamp field, and set the CSRC list, header extension and
        padding to null regardless of the values of the CC field, X bit
        and P bit.
This is not clear at all to me (even if I understand the intent).
The structure of the bit string is the same, but the values are the
ones that have been received. So, saying "compute the XXX field in
the same fashion..." is misleading, as well as "XXX recovery field".

I suggest:
   2.   For the repair packet associated with set T, construct the bit
        string similarly, using the values received in the repair
        packet for the PT and TS fields, ...

11/** Section 6.3.2. "Recovering the RTP Header and Payload", p 25

I also suggest a different ordering, since as such there is an
incoherency: In step 1, we cannot "compute the bit string as described
in section 6.2", since we still don't know at this stage the maximum
length, and so the required padding.
But if we switch the order, everything works well.

I suggest (reorder + merge):
1. For the repair packet...
2. For each of the source packets, ... If the bit string generated
   is shorter than the string generated for the repair packet...

12/** Section 6.3.2. "Recovering the RTP Header and Payload", p 25
It is said, in step 14:
   14.  Take the next 16 bits of the recovered bit string and set Y to
        whatever unsigned integer this represents (assuming network-
        order).  Take Y bytes from the recovered bit string...
Two points:
 - I suggest saying explicitly that "Y" is a new unsigned integer
   variable (it was not clear to me when reading it first);
 - I also suggest saying explicitly that Y must first be converted
   to host order, otherwise funny things will happen on our little
   endian machines ;-)

To summarize, I suggest:
   14.  Take the next 16 bits of the recovered bit string and set
        the new variable Y to whatever unsigned integer this represents
        (assuming network-order). Convert Y to host byte order and then
        take Y bytes from the recovered bit string...

13/** Section 13.2 "Informative references"
Why is reference RFC2733 in the informative section whereas the goal 
of this document is to "extend the Forward Error Correction (FEC) header
defined in [RFC2733]"? It deserves a Normative Ref IMHO.

II- Typos and minor comments
----------------------------

** Section 3.3: I don't think that the bitwise table of XOR sums is needed.

** Section 6.3.  Source Packet Reconstruction, p24:
I suggest (1st sentence):
   ...reconstruct the missing source packets.
                              ^^^^^^

** Section 6.3.1, p25:
   if there is only one source packet missing in set T. 
                                    ^^^^ (removed "is")

** Section 7, SDP example.
We can probably remove the extra " " space in "repair-window: 200000"
(i.e., like the other parameters).

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 4 May 2009 14:27:39 -0700

Thanks for the detailed review. I'll get most of them into the next revision. I have some comments for some of them, though. Inline.

1/** Introduction, p.4
It is said:

I suggest:

Ali: Sounds good.

Ali: This should rather go to the framework draft.

2/** Section 4.2, p13:
It is said:

Ali: If two RTP streams are sent to different IP addresses, they are different RTP sessions anyway. Random SSRCs help when we send two RTP streams in the same RTP session. Source address/port is irrelevant. So, I don't see any confusion here.

3/** Fig. 3: 

       XOR sum of set
       +-------------+
       | S_1         |
       | S_L+1       |
       | .           |
       | .           |
       | .           |
       | S_(D-1)xL+1 |
       +-------------+
              =      
            +===+   
            |C_1|  
            +===+ 

Ali: I believe the context is clear here as the source, repair and operation are encapsulated differently.

Ali: I am sorry but I don't get your point. I could say "applying XOR operation" but the difference is negligible.

5/** Section 4.2, p 15:

Ali: I could say "systematized" if you like it better because systematic or systematized captures what I would like to say.

6/** Section 5.2.1, p21:
It is said:

Ali: OK

7/** Section 6, p.22:
It is said:

Ali: OK

8/** Section 6, p.23:
It is said:

Several issues:

Ali: Right.

Ali: Within this source block and I believe it is pretty clear.

Ali: The first item above will take care of this.

Ali: I'd agree with this. But 2733 did not use "always" in the text. Not sure whether we should stick with it, though.

Ali: Yes, wrapping should be taken into account.

I suggest:

Ali: No. We need to explicitly say the "PT/TS recovery fields" here since there are also the PT and TS fields in the RTP header.

Ali: Not that this is incorrect, but the current text is not incorrect, either. Padding does not change the bitstring and necessary padding can always be added. I suggest to keep the current text to be consistent with 2733.

To summarize, I suggest:

Ali: Sounds good.

Ali: Because it has been obsoleted and the fact that the current spec does not need RFC 2733 to be implemented. 

Ali: Good idea.

** Section 6.3.1, p25:

Ali: Good catch.

Ali: We should. 

Thanks,
-acbegen

> From: Vincent Roca [mailto:[email-masked]]
> Sent: Monday, May 04, 2009 8:10 AM
> To: Marshall Eubanks; Ali C. Begen (abegen)
> Subject: Re: [Fecframe] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-04
> 
> Hello Ali,
>

---

From: Vincent Roca <[email-masked]>
Date: Tue, 05 May 2009 16:45:44 +0200

Hello Ali,

A few answers inline, after removing the points where we agree.

[...]
> Ali: This should rather go to the framework draft.

VR: Since the intent was to keep this document more or less
    independent from the framework I-D, it would make sense to
    put it here too.

> Ali: If two RTP streams are sent to different IP addresses, they are different
> RTP sessions anyway. Random SSRCs help when we send two RTP streams in the same
> RTP session. Source address/port is irrelevant. So, I don't see any confusion here.

VR: No, there is a confusion. Imagine that the sender uses different
    destination addresses, but the same destination port.
    In that case we don't need the SSRC. Saying "on the same port"
    without saying "and the same destination address" is misleading.
    I suggest:

	This allows the sender to multiplex the source and repair
        flows on the same RTP session (i.e., same destination address
        and port), or multiplex multiple repair flows on the same RTP
        session.

> Current figure looks like the following:

VR: you're right, the encapsulation is different, I didn't notice.
    However I still don't like the XOR box which remains misleading
    IMHO. But you are the editor, I let you decide.

> but the difference is negligible.

VR: I don't like "by applying protection" or "by applying XOR operation"
    in the sentence and prefer my wording. Here also, you are the editor.

> Ali: I'd agree with this. But 2733 did not use "always" in the text. Not
> sure whether we should stick with it, though.

VR: I was not aware of the RFC2733 wording. In any case, if there's a
    small mistake in this RFC, I don't see any good reason to reproduce
    it here.

> Ali: No. We need to explicitly say the "PT/TS recovery fields" here since
> there are also the PT and TS fields in the RTP header.

VR: Oups, you're right! I forgot that the "TP (resp. TS) recovery field"
    comes from the FEC Header. We can perhaps clarify the original
    wording to avoid such a mistake in the future (even if it's now clear
    to me):

    2.   For the repair packet associated with set T, compute the bit
         string in the same fashion, except that we use the PT (resp. TS)
         recovery field of the FEC header instead of the PT (resp.
         Timestamp) field of the RTP header,...

> Ali: Not that this is incorrect, but the current text is not incorrect,
> either. Padding does not change the bitstring and necessary padding can
> always be added. I suggest to keep the current text to be consistent with 2733.

VR: As you want, but I'll swap the order if I implement it ;-)

Cheers,

   Vincent