Subject: [AVT] Updates to draft-ietf-avt-ulp

From: "Adam Li" <[email-masked]>
Date: Wed, 22 Feb 2006 18:46:17 -0800

Chairs, Mark, All, 

An updated version of the ULP draft has just been submitted. It may also be
obtained through anonymous FTP at
ftp://ftp.hyervision.com/pub/IETF/ULP/draft-ietf-avt-ulp-15.txt before the
ID manager updates the database.

Most of the comments received in WGLC are updated into the latest version of
the draft. Thanks a lot for Mark's detailed reading and suggestions. I have
some line-by-line comments on the comments from Mark as following. 

Your helps are all very much appreciated.

Adam

A) Technical aspects with respect to FEC

A.1) Specification of the decoding algorithm

What Mark pointed out is a very valuable point to deal with scenarios when a
given payload packet is protected by multiple FEC packets at the same level.
In this document, we specify the transmission protocol and the recovery
operations, but leave the recovery algorithm to the implementer, as
discussed in Para 2 of Section 9. So I think we do not need to discuss these
cases.

A.2) Relationship between levels

First of all, I do agree that even with our restriction in protection
levels, there are finite probability that partially recovered data can be at
the higher level. That is the reason we use "almost always" instead of
"always". 

When in use, the sender will usually want to choose a protection group size
that have payload recoverable (at least for the lower level) in majority of
the cases. The 2-loss scenarios would be rare, and even under it there are
only 2 cases where partial recovery of ends happens. In additional, the
group size 2 is used in example so I don't have to draw too many blocks, and
the group size N is usually larger. The total cases goes as O(N^2) while the
partial recovery of ends goes as O(N). So I think it is fair to say "almost
always". Or how about "in majority of the cases"?

A.3) Applicability

Agreed. Updated as suggested.

B) Opinions on FEC-related aspects

B.1) "Unequal Level Protection" vs "Unequal Erasure Protection"

I do agree with you that "Unequal Erasure Protection" needs to be used
carefully. It requires first breaking payload data and fill into a group of
intermediate packets, then sort-of "cross-hash" those packets into a new
group of packets to be transmitted. It is probably a little too complicated
to be summarized in a sentence in this draft, so I assumed the reader of
this section have know how both works. I am simply pointing out the strength
and comparison between the two schemes.

B.2) Value of Unequal Level Protection

Yes, it is a subtle issue as you said. And I do see your point. I usually
use relative terms and tried to avoid any strong broad assertion. I will
comb through the draft to see if there are any unnecessary overbroad
statements and will change them if I see one.

B.3) Section 5, Second Paragraph

Agreed. Updated as suggested.

C) Some technical comments on the specification text
D) Editorial

Mostly updated. Some with different wording from suggested. 

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

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 23 Feb 2006 17:38:23 +0100

Hi,

Please review the changes. If you have any comments or issues, please 
state them soon. We would like to wrap this work up.

Cheers

Magnus

-- 

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Colin Perkins <[email-masked]>
Date: Mon, 27 Feb 2006 16:43:29 +0000

Adam, all,

> ID manager updates the database.

I have some minor comments after a careful reading of this latest  
version:

For consistency with other RTP Payload Formats, and to meet RFC  
Editor guidelines for acronym expansion, please change the title to  
"RTP Payload Format for Generic Forward Error Correction".

In figures 1 and 2, I suggest changing the label from "RTP Header" to  
"RTP Header (at least 12 octets)".

The introduction to Section 7.3 is ungrammatical. Can you reword the  
first sentence ("The RTP header for FEC packets are used..."),  
perhaps as "...is only used..."?

Section 11 should be renamed to "Security Considerations".

The 2nd and 3rd paragraphs of section 11 are a little confusing. Is  
there a use case for encryption before FEC? If not, it might be  
easier just to state that FEC must be done before encryption, remove  
the 2nd paragraph, and clarify the 3rd.

Can you quickly update the draft to address these (before the  
deadline next Monday)?

> some line-by-line comments on the comments from Mark as following.

We'll wait for confirmation from Mark that the updates address his  
concerns before proceeding.

Colin

---

From: "Adam Li" <[email-masked]>
Date: Tue, 28 Feb 2006 13:31:38 -0800

Hi Colin,

Thanks a lot for the comments. The draft is updated with the
recommendations, and a new revision (-16) is just submitted to the ID
manager. 

About Section 11 "Security Considerations", FEC can be applied either before
or after encryption. Both cases are valid cases, so I kept both of them. As
discussed in paragraph 2, when FEC is applied after, the FEC data is secure,
so no additional security measure is needed. When FEC is applied before, the
FEC data need to be encrypted as well. The rest of the section (from
paragraph 3 and on) focuses on the security considerations for that
scenario. 

Thank you.

Adam

> -----Original Message-----
> From: Colin Perkins [mailto:[email-masked]]
> Sent: Monday, February 27, 2006 8:43 AM
> To: Adam Li
> Cc: IETF-AVT
> Subject: Re: [AVT] Updates to draft-ietf-avt-ulp
> 
> Adam, all,
>

---

From: Colin Perkins <[email-masked]>
Date: Tue, 28 Feb 2006 21:36:01 +0000

Hi Adam,

> paragraph 3 and on) focuses on the security considerations for that

Is there any benefit to having both? It would ease interoperability  
if there were only one way of doing the encryption.

Colin

---

From: "Adam Li" <[email-masked]>
Date: Tue, 28 Feb 2006 20:53:42 -0800

Hi Colin,

Restricting that FEC has to be before or after encryption is too limiting, I
think, especially because the encryption can be in a lot of different ways
other than SRTP. That section is concerning about the security consideration
in general and thus it may be necessary to talk about the issues one might
need to consider if encryptions are done in all different configurations. 

Adam

> Sent: Tuesday, February 28, 2006 1:36 PM
> To: Adam Li
> Cc: 'IETF-AVT'