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

["Ali C. Begen (abegen)" <[e-mail]>]

> -----Original Message-----
> From: Colin Perkins [mailto:[e-mail]]
> Sent: Wednesday, October 06, 2010 4:17 PM
> To: Ali C. Begen (abegen)
> Cc: David Harrington; [e-mail]; TSV Dir; [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,
> 
> 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?

I guess the goal was when someone defined a new proto, they would not necessarily be aware of the fec framework and later one wanted to use that proto with fec framework, he would need a registration (which requires a new spec). 

But, I am pretty much fine with removing that part and simply registering UDP for now. Unless anybody has any objections, I will revise the draft and we can publish it? Any objections?

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