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

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.

> 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?

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."

> 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.

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.

> - It is suggested that multiple FEC schemes can be used when there
>   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. 

> 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.).

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
>   for source flows?

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

> - Is the FSSI sufficient to carry all FEC related parameters (see
>   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.

> - 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.

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.

> 
> 
> 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?

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

> _______________________________________________
> Fecframe mailing list
> Fecframe@ietf.org
> https://www1.ietf.org/mailman/listinfo/fecframe
> 

_______________________________________________
Fecframe mailing list
Fecframe@ietf.org
https://www1.ietf.org/mailman/listinfo/fecframe