Subject: [Fecframe] a few comments on draft-begen-fecframe-sdp-elements-00

From: Vincent Roca <[email-masked]>
Date: Mon, 03 Dec 2007 23:55:29 +0100

Dear Ali,

I've read you I-D and have a few comments. Some of them
are probably a little bit naive, sorry in advance. They may also
reflect the fact that the document is not selft-sufficient...

Cheers,

  Vincent

1/ What are the relationships between this document and the RFC5052
(FEC Building Block)? This document is not mentionned at all in the
references while there are implicit references.
More specifically:
- how does the concept of "scheme ID" relate to the "fully specified
  FEC scheme" or "undert-specified FEC scheme"? Is it an {FEC Enc. ID/
  FEC Inst. ID} equivalent (or FEC Enc. ID in case of fully-specified
  scheme)? Clarification needed e.g., for section 3.3/bullet 3.
  This clarification is also needed since the document says that "Scheme
  ID needs to be registered with IANA" (section 4.5).
- is the FSSI the same as the "Scheme Specific Elements" of RFC5052?

2/ section 3.3, bullet 4:
- This paragraph is a little bit obscure.
  Instead of:
    "However, in the case that the Explicit Source FEC Payload ID is used"
  I think the author should say:
   "A value is greater than zero indicates that an explicit Source
    FEC Payload ID is used. However, in that case, only one FEC scheme..."
- This paragraph does not indicate nor give any reference to the concept
  of "generic tag". The terms "tag" and "Source FEC Payload ID" seem to
  refer to the same thing, but it's not clearly stated.
- It is suggested that multiple FEC schemes can be used when there
  is no explicit Source FEC Payload ID. Is that true and why?

3/ section 3.3, list of FEC Framework Config Info:
Is this list exhaustive? For instance:
- repair flows (bullet 1) are "identified", but not "defined"
  (unlike source flows, bullet 2.).
- Is the identifier used for repair flows similar to the one used
  for source flows?
- Is the FSSI sufficient to carry all FEC related parameters (see
  the question 1/ above on the relationship with RFC5052)?
- the length of the FEC Payload ID is mentioned here, but not its
  content/format. Is it implied by the FEC Scheme (in a way similar
  to RFC5052)? This should be clarified.

4/ section 4.1 Transport protocol identifiers
The differences between "fec/udp" and "udp/fec" are not clear.
Latter on, in section 7 "IANA considerations", only two <proto>/FEC
(in upper case this time) are defined.

5/ section 4.2: example in fig. 1
The example shows a complex source/repair mapping. Is this example
realistic or is it a "view of the mind" meant to illustrate the
flexibility of the underlying FEC framework?

6/ General question:
Parameters carried within a Session Announcement are by nature
applicable to the whole session. Is that sufficient or do we
lack some flexibility to reflect a dynamic change in the session
(e.g. when new source flows are added to the "group", or some source
flows diseapper from the "group")?

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

---

From: "Ali Begen (abegen)" <[email-masked]>
Date: Tue, 4 Dec 2007 11:50:02 -0800

Hi Vincent. 

Thanks for the questions. Pls see inline. 

> 1/ What are the relationships between this document and the 
> RFC5052 (FEC Building Block)? This document is not mentionned 
> at all in the references while there are implicit references.

There are many similarities between the RMT and FECFrame WGs. If
necessary, I will include appropriate references in the next submission.

> - is the FSSI the same as the "Scheme Specific Elements" of RFC5052?

Scheme IDs have to be registered with IANA. See the framework draft
Section 6.6. It has all the details regarding the FEC Scheme
requirements. I believe the SDP draft should just mention about these
requirements in a summarized form. 

Regarding the FSSI field, it is everything that the FEC scheme requires
specifically for a proper operation. The details of what will be
included in that field depends on the FEC scheme. So, it is pretty much
the same thing the RFC 5052 refers to as "Scheme-Specific FEC Object
Transmission Information Element."

>   refer to the same thing, but it's not clearly stated.

I will make this more clear in the next submission. Generic tag, I
believe, should be defined in the framework draft, not in here. Good
point.

>   is no explicit Source FEC Payload ID. Is that true and why?

Yes, if none of those FEC schemes modify the source packets, you can use
any number of different repair flows to protect the source flow. 

>   (unlike source flows, bullet 2.).

Repair flows are already defined by their protocol identifiers. But for
the source flow, we need a common way within the framework instance to
define them. Once we know how to define them, we assign identifiers to
them as we do the same for the repair flows. 

> - Is the identifier used for repair flows similar to the one used

Yes, internally we will simply use integer identifiers for both repair
and source flows.

>   the question 1/ above on the relationship with RFC5052)?

It should be. If some information about the scheme cannot be put
somewhere in the common fields of the SDP, it will go to the FSSI field.

>   to RFC5052)? This should be clarified.

Are you suggesting I should define the "Source FEC Payload ID" here?
And, yes, the FEC scheme determines the length of this field. 

> 
> 
> 4/ section 4.1 Transport protocol identifiers The differences 
> between "fec/udp" and "udp/fec" are not clear.

'fec/udp' is for the source flows. And 'udp/fec' is for the repair
flows. 

> Latter on, in section 7 "IANA considerations", only two 
> <proto>/FEC (in upper case this time) are defined.

I'll fix this.

> The example shows a complex source/repair mapping. Is this 
> example realistic or is it a "view of the mind" meant to 
> illustrate the flexibility of the underlying FEC framework?

The goal is to illustrate that we support complex combination of
source/repair flows. It is not necessarily the best or the only to do
what you want to do.

> 
> 
> 6/ General question:
> Parameters carried within a Session Announcement are by 
> nature applicable to the whole session. Is that sufficient or 
> do we lack some flexibility to reflect a dynamic change in 
> the session (e.g. when new source flows are added to the 
> "group", or some source flows diseapper from the "group")?

This is a valid question. In case there is a change in the offerings, a
new SDP should be sent to the receiver(s), I believe. We are not doing
in-band signaling. So, sending a new SDP is probably the easiest
solution. 

Let me know if I skipped something.

-acbegen