Re: [Fecframe] [IANA #394228] RE: LastCall:<draft-ietf-fecframe-sdp-elements-08.txt> (SessionDescriptionProtocol (SDP) Elements for FEC Framework) toProposed Standard

[Colin Perkins <[e-mail]>]

Hi,

On 2 Oct 2010, at 12:34, Ali C. Begen (abegen) wrote:
>> -----Original Message-----
>> From: David Harrington [mailto:[e-mail]]
>> Sent: Saturday, October 02, 2010 12:53 AM
>> To: Ali C. Begen (abegen); [e-mail]; 'TSV Dir'
>> Cc: [e-mail]; [e-mail]
>> Subject: RE: [Fecframe] [IANA #394228] RE: LastCall:<draft-ietf- 
>> fecframe-sdp-elements-08.txt> (SessionDescriptionProtocol
>> (SDP) Elements for FEC Framework) toProposed Standard
>>
>> Hi Ali,
>>
>> Thanks for responding.
>> I probably should have questioned this more during AD Review. I did  
>> think it an odd design, but there was apparently WG consensus, so I  
>> didn't bother to raise my questions. My bad.
>>
>> When you say "someone wants to use it as a source flow in the fec
>> framework", this is not very clear. The fec framework is an  
>> abstract description of how things fit together. Within the fec  
>> framework, we have multiple fec schemes. Is each fec scheme  
>> designed to protect specific types of source flows?
>
> Right, framework draft explains the framework itself. The FEC  
> schemes may have individual requirements for the source (input)  
> flows. In some source flows, sequence numbers will already exist to  
> allow the receiver to identify them uniquely (like RTP). In other  
> source flows (such as UDP), there won't be a seqnum which means  
> something needs to be added at the end of the source packets  
> (explicit source fec payload id). However, once we do that, we  
> cannot describe those packets as regular UDP packets since it would  
> be misleading. Instead, we use FEC/<proto> in the SDP. This way, a  
> receiver that does not implement the framework will not be able to  
> parse FEC/<proto> line and it will not try to use that flow.
>
>> When you say "someone wants to use it as a source flow in the fec
>> framework", is the someone the editor of a fec scheme specification?
>
> Suppose your source flow is UDP. And you wanna apply FEC on it. So,  
> you append the explicit source fec payload id. Now, in the SDP you  
> should use "FEC/UDP." But I think you can only do it if it has been  
> registered with IANA. It does not matter who does the registration.  
> If an FEC scheme draft registers it, others can use it as well since  
> "FEC/UDP" part is common (different FEC schemes will be identified  
> based on their encoding IDs anyway).
>
> So bottom line is, either the SDP draft registers it or an FEC  
> scheme draft that plans to use UDP flows as source flows registers  
> it. Once it is registered, other FEC schemes can use the same  
> registration.
>
>> is "it" a registered identifier?
>> What exactly does the identifer identify?
>> Does that identifier identify a specific fec scheme for a specific
>> type of source flow?
>> Would it make sense for a fec scheme specification document to
>> register the specific relevant identifiers?
>
> I hope my answer above answers all these questions. FEC schemes are  
> identified by their encoding IDs not protocol identifiers.
>
>> Please try to be very explicit in your response, so I can understand
>> this better.
>> It might help to avoid using pronouns like "someone", "it", and
>> phrases like "the ones we care about"
>> I care about all standard protocols ;-) Which ones do you care about?
>
> Sure. Certain protocols will unlikely to be used with FEC (e.g.,  
> TCP). And for RTP and DCCP (which has its own seqnums), we don't  
> need a new identifier. So, to me UDP is the #1 candidate :) So we  
> can do the registration for UDP and leave the rest for future FEC  
> scheme drafts.


I'm also uncomfortable with the idea of automatic registration of SDP  
proto values, since it's not clear that they all make sense to use  
with FEC. What's the reason for this, rather than just registering  
them when needed?

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