Subject: Re: [Fecframe] Review for draft-ietf-fecframe-raptor-01

From: "Watson, Mark" <[email-masked]>
Date: Tue, 5 Jan 2010 18:35:42 -0800

Ali, all,

Sorry for the small delay.

My responses to your comments are inline below with the exception of the last one regarding FS-FSSI and FSSI encoding: Sorry I missed the discussion on that. I am confused about what "multiple distinct elements" means in the SDP elements draft: you define the FSSI it to be just *CHAR - no notion of 'element' is defined.

A consequence of this decision is that the FEC Framework must require FEC Schemes to define a text format for the SS-FSSI and FSSI (so I need to add that) and furthermore that this format must not include the ';' character or Carriage Return (otherwise things become ambiguous in the SDP case). This seems a little arbitrary (SDP-specific encoding requirements polluting the FEC framework), but I guess that's my fault for missing the discussion.

What did you decide regarding binary encodings ? Must FEC Schemes define these or must all CDPs provide for text transport ?

...Mark

On 10/29/09 12:05 PM, "Ali C. Begen (abegen)" <[email-masked]> wrote:

- Abstract says " An RTP Payload Type is defined for this latter case. " I'd suggest to remove this sentence as this draft does not provide the payload format.

MW: ok

- Also in the abstract and introduction, it says two FEC schemes are defined. In the Raptor RTP draft, it said three. You might wanna fix it for consistency.

MW: Ok, there are three.

- Introduction:

   Per the FEC Framework requirements, the sender MUST transmit the
   source and repair packets in different source and repair flows,
   respectively.

In case of RTP transport, source and repair data can be in different RTP streams, where they are SSRC multiplexed in the same RTP session. From outside, they look like a single UDP flow. The sentence above contradicts with this. I suggest to change it as follows:

   Per the FEC Framework requirements, the sender MUST transmit the
   source and repair packets in different source and repair streams,
   respectively.

MW: I suggest "Per the FEC Framework requirements, the sender MUST transmit the source and repair packets in different source and repair flows, or in the case RTP transport is used for Repair packets, in different RTP streams."

Accordingly, the definitions (source and repair flow) will need to be changed as well in section 4.

MW: ok

- I admit that I did not check all the definitions/formulas in sections 6-8 in detail.

- Section 8.2.4. What about the length of the RTP header extensions?

MW: Good point. In DVB the X bit was not allowed to be set, so the header extension was not mentioned. I will add it.

- Section 9: No specific security considerations?

MW: Not that I can think of. We define here specific encodings and packet formats but the same security issues apply however this information is encoded and are dealt with in the FEC framework. I will add a note to this effect.

- Section 10: I suggest to reference 4756bis instead of 4756 and update the semantics accordingly. Also "a=repair-window: 200" should be "a=repair-window:200" (remove the space).

MW: Ok.

...Mark

- As agreed in the last meeting, the current SDP elements draft says:

   The variable-length SS-FSSI and FSSI containers transmit the
   information in textual representation and MAY contain multiple
   distinct elements.  For the fully-specified FEC schemes, a full
   description of these elements for both containers MUST be provided.

This will require some changes in the SDP example. The draft also needs to explain the elements that will be used in this textual representation.

HTH,
-acbegen

_______________________________________________
Fecframe mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/fecframe

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sat, 9 Jan 2010 17:08:23 -0800

Hi Mark,

> My responses to your comments are inline below with the exception of the last one
> regarding FS-FSSI and FSSI encoding: Sorry I missed the discussion on that. I am confused
> about what “multiple distinct elements” means in the SDP elements draft: you define the
> FSSI it to be just *CHAR – no notion of ‘element’ is defined.

Here is an example from the SDP draft:

        a=fec-repair-flow: encoding-id=0; ss-fssi=n:7,k:5

n, k are distinct elements, and the ss-fssi is a *char.

> 
> A consequence of this decision is that the FEC Framework must require FEC Schemes to
> define a text format for the SS-FSSI and FSSI (so I need to add that) and furthermore that
> this format must not include the ‘;’ character or Carriage Return (otherwise things become
> ambiguous in the SDP case). This seems a little arbitrary (SDP-specific encoding
> requirements polluting the FEC framework), but I guess that’s my fault for missing the
> discussion.

I believe this was voted in Stockholm and I had sent an email in the list.
 
> CDPs provide for text transport ?

All need to provide text transport.
 
> 	In case of RTP transport, source and repair data can be in different RTP streams,
> where they are SSRC multiplexed in the same RTP session. From outside, they look like a
> single UDP flow. The sentence above contradicts with this. I suggest to change it as
> follows:
> 
> MW: I suggest “Per the FEC Framework requirements, the sender MUST transmit the source and
> repair packets in different source and repair flows, or in the case RTP transport is used
> for Repair packets, in different RTP streams.”

Sure, it should be "repair packets" not "Repair packets". Also you might wanna divide this into two sentences rather than a big sentence.
 
> not mentioned. I will add it.

OK.
 
> MW: Not that I can think of. We define here specific encodings and packet formats but the
> same security issues apply however this information is encoded and are dealt with in the
> FEC framework. I will add a note to this effect.
> 

Good idea. 

-acbegen

---

From: "Watson, Mark" <[email-masked]>
Date: Mon, 11 Jan 2010 09:43:30 -0800

Hi Ali,

See inline...

...Mark

On 1/9/10 5:08 PM, "Ali C. Begen (abegen)" <[email-masked]> wrote:

Hi Mark,

> about what "multiple distinct elements" means in the SDP elements draft: you define the
> FSSI it to be just *CHAR - no notion of 'element' is defined.

Yes, well, I can see that because I am a human being with some reasonably advanced cognitive functions ;-) But there is no sense of element defined in a formal sense that I could implement.

The options are to define some kind of syntax (e.g. comma-separated list of <name> ":" <value> pairs) that all FEC Schemes must use, or to leave it as an opaque field for the FEC Scheme to define the syntax, subject to the framing rules imposed by the attribute definition.

> this format must not include the ';' character or Carriage Return (otherwise things become
> requirements polluting the FEC framework), but I guess that's my fault for missing the
> discussion.

I don't believe the details above were addressed.

So, this change needs to be made in the Framework.

> MW: I suggest "Per the FEC Framework requirements, the sender MUST transmit the source and
> for Repair packets, in different RTP streams."

OK.

Good idea.

-acbegen

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 11 Jan 2010 12:02:47 -0800

> Yes, well, I can see that because I am a human being with some reasonably advanced
> cognitive functions ;-) But there is no sense of element defined in a formal sense that I
> could implement.

:)
 
> The options are to define some kind of syntax (e.g. comma-separated list of <name> “:”
> <value> pairs) that all FEC Schemes must use, or to leave it as an opaque field for the
> FEC Scheme to define the syntax, subject to the framing rules imposed by the attribute
> definition.

I believe the former of what you said above is a good syntax. Could we get it in the framework draft?
 
> I don’t believe the details above were addressed.
> 
> 
> 
> 	> What did you decide regarding binary encodings ? Must FEC Schemes define these or
> must all
> 	> CDPs provide for text transport ?
> 

Yes.

-acbegen