Subject: Re: [Fecframe] [IANA #394228] RE: Last Call:<draft-ietf-fecframe-sdp-elements-08.txt> (Session DescriptionProtocol (SDP) Elements for FEC Framework) to Proposed Standard

From: "David Harrington" <[email-masked]>
Date: Fri, 1 Oct 2010 23:39:25 -0400

Hi fecframe, 

I didn't like this much when I did my AD review and I still don't.
I think this puts tremendous load on IANA to do this for us
automatically for every current and future registration.
Can we please design a different approach to FEC registration.
I think there must be a simpler manner to do this.

TSVDIR, can you suggest a better approach for this?

David Harrington
Director, IETF Transport Area
[email-masked] (preferred for ietf)
[email-masked]
+1 603 828 1401 (cell)

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Amanda Baber via RT
> Sent: Friday, October 01, 2010 8:53 PM
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: [IANA #394228] RE: Last 
> Call:<draft-ietf-fecframe-sdp-elements-08.txt> (Session 
> DescriptionProtocol (SDP) Elements for FEC Framework) to 
> Proposed Standard
> 
> Hi Ali,
> 
> Just to make sure we understand what you're asking for: you 
> want this document to modify the registration procedures for 
> the proto registry to be modified so that for every current 
> and future registration -- RTP/AVP, vat, TCP, et al. -- IANA 
> would also automatically register FEC/RTP/AVP, FEC/vat, 
> FEC/TCP, and so on?
> 
> This sounds like a decision for the ADs. We're able do this 
> -- we'd just  have to insert a note in the registry 
> instructing ourselves to do it -- but we can't think of any 
> other registries that behave this way. 
> 
> Thanks,
> 
> Amanda
> IANA
> 
> On Thu Sep 23 19:55:01 2010, [email-masked] wrote:
> > Hi Amanda,
> > 
> > We cleared the earlier issues with this draft. However, during the
> >    IESG review something came up. This is about section 4.1. In
> >    addition to registering UDP/FEC, we also need several other
> >    registrations for FEC/<proto> for the proto's listed in the SDP
> >    registry. I wonder how we can do this effectively. A shortcut
> >    maybe?
> > 
> > I am probably pushing the limit here. But I wonder whether we
could
> >    define something here so that when a new proto is 
> registered in the
> >    future, FEC/<proto> can also be automatically registered based
on
> >    this draft.
> > 
> > I am about to revise this draft. I would appreciate if you 
> could tell
> >    me what I should put in section 8.1 regarding the above.
> > 
> > Thanks in advance.
> > 
> > -acbegen
> > 
> > > -----Original Message-----
> > > From: Amanda Baber via RT [mailto:[email-masked]]
> > > Sent: Friday, September 10, 2010 3:05 PM
> > > Cc: Ali C. Begen (abegen); [email-masked];
> >    [email-masked]
> > > Subject: [IANA #386944] Last Call: <draft-ietf-fecframe-sdp-
> >    elements-08.txt> (Session Description Protocol (SDP) Elements
for
> > > FEC Framework) to Proposed Standard
> > >
> > > IESG:
> > >
> > > IANA has reviewed 
> draft-ietf-fecframe-sdp-elements-08.txt, which is 
> > > currently in Last Call, and has the following comments:
> > >
> > > IANA has questions about this document.
> > >
> > > IANA understands that, upon approval of this document, 
> there are two 
> > > IANA Actions that need to be completed.
> > >
> > > First, in the proto type subregistry of the Session Description
> >    Protocol
> > > (SDP) Parameters located at:
> > >
> > > http://www.iana.org/assignments/sdp-parameters
> > >
> > > a single new value is to be registered:
> > >
> > > Type SDP Name Reference
> > > ----- ---------- -----------
> > > proto UDP/FEC [RFC-to-be]
> > >
> > > Second, in one of the att-field subregistries of the Session
> >    Description
> > > Protocol (SDP) Parameters located at:
> > >
> > > http://www.iana.org/assignments/sdp-parameters
> > >
> > > three new attribute names are to be added as follows:
> > >
> > > SDP Attribute ("att-field"):
> > > Attribute name: fec-source-flow
> > > Long form: Pointer to FEC Source Flow Type of name: 
> att-field Type 
> > > of attribute: Media level Subject to charset: No
> > > Purpose: Provide parameters for an FEC source flow
> > > Reference: [RFC-to-be]
> > > Values: See [RFC-to-be]
> > >
> > > SDP Attribute ("att-field"):
> > > Attribute name: fec-repair-flow
> > > Long form: Pointer to FEC Repair Flow Type of name: 
> att-field Type 
> > > of attribute: Media level Subject to charset: No
> > > Purpose: Provide parameters for an FEC repair flow
> > > Reference: [RFC-to-be]
> > > Values: See [RFC-to-be]
> > >
> > > SDP Attribute ("att-field"):
> > > Attribute name: repair-window
> > > Long form: Pointer to FEC Repair Window Type of name: 
> att-field Type 
> > > of attribute: Media level Subject to charset: No
> > > Purpose: Indicate the size of the repair window
> > > Reference: [RFC-to-be]
> > > Values: See [RFC-to-be]
> > >
> > > IANA has a question about these registrations. There are four
att-
> >    field
> > > registries: one for session level attributes, one for both
session
> >    and
> > > media level attributes, one for media level attributes 
> only, one for 
> > > source level, and a final one for attributes for unknown levels.
> >    Which
> > > of these subregistries are these three attribute names to be
added
> >    to?
> > >
> > > After clarification, IANA understands that these are the only
> >    actions
> > > required upon approval of the document.
> > >
> > > Thanks,
> > >
> > > Amanda Baber
> > > IANA
> > >
> > > On Fri Aug 27 15:50:26 2010, [email-masked] wrote:
> > > >
> > > > The IESG has received a request from the FEC Framework WG
> >    (fecframe) to
> > > > consider the following document:
> > > > - 'Session Description Protocol (SDP) Elements for FEC 
> Framework'
> > > >   <draft-ietf-fecframe-sdp-elements-08.txt> as a 
> Proposed Standard
> > > >
> > > > The IESG plans to make a decision in the next few weeks, and
> >    solicits
> > > > final comments on this action. Please send substantive 
> comments to
> >    the
> > > > [email-masked] mailing lists by 2010-09-10. 
> Exceptionally, comments
> >    may be
> > > > sent to [email-masked] instead. In either case, please 
> retain the 
> > > > beginning of the Subject line to allow automated sorting.
> > > >
> > > > The file can be obtained via
> > > > 
> https://datatracker.ietf.org/doc/draft-ietf-fecframe-sdp-elements/
> > > >
> > > > IESG discussion can be tracked via 
> > > > 
> https://datatracker.ietf.org/doc/draft-ietf-fecframe-sdp-elements/
> > > >
> > > >
> > > > No IPR declarations were found that appear related to this
I-D.

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 1 Oct 2010 20:48:08 -0700

One alternative is to register the ones we care about now, and if a new protocol is defined in the future and then later someone wants to use it as a source flow in the fec framework, then, they register it with IANA. In other words, the registration stays "on demand".

One way or another, the flows of the modified source packets have to be described in the SDP. So, a transport protocol identifier is required.

-acbegen

> From: [email-masked] [mailto:[email-masked]] On Behalf Of David Harrington
> Sent: Friday, October 01, 2010 11:39 PM
> To: [email-masked]; 'TSV Dir'
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Fecframe] [IANA #394228] RE: LastCall:<draft-ietf-fecframe-sdp-elements-08.txt> (SessionDescriptionProtocol
> (SDP) Elements for FEC Framework) toProposed Standard
> 
> Hi fecframe,
> 
> _______________________________________________
> Fecframe mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/fecframe

---

From: "David Harrington" <[email-masked]>
Date: Sat, 2 Oct 2010 00:53:20 -0400

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?

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

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?

David Harrington

> From: Ali C. Begen (abegen) [mailto:[email-masked]] 
> Sent: Friday, October 01, 2010 11:48 PM
> To: David Harrington; [email-masked]; TSV Dir
> Subject: RE: [Fecframe] [IANA #394228] RE: 
> LastCall:<draft-ietf-fecframe-sdp-elements-08.txt> 
> (SessionDescriptionProtocol (SDP) Elements for FEC Framework) 
> toProposed Standard
> 
> One alternative is to register the ones we care about now, 
> and if a new protocol is defined in the future and then later 
> someone wants to use it as a source flow in the fec 
> framework, then, they register it with IANA. In other words, 
> the registration stays "on demand".
> 
> One way or another, the flows of the modified source packets 
> have to be described in the SDP. So, a transport protocol 
> identifier is required.
> 
> -acbegen
> 
> > From: [email-masked] 
> [mailto:[email-masked]] On 
> > Behalf Of David Harrington
> > Subject: Re: [Fecframe] [IANA #394228] RE: 
> > LastCall:<draft-ietf-fecframe-sdp-elements-08.txt> 
> > (SessionDescriptionProtocol
> > > From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> > > Of Amanda Baber via RT
Proposed 
> > > Standard
> > >
> > > Hi Ali,
> > >
> > > Just to make sure we understand what you're asking for: you want

> > > this document to modify the registration procedures for the
proto 
> > > registry to be modified so that for every current and future 
> > > registration -- RTP/AVP, vat, TCP, et al. -- IANA would also 
> > > automatically register FEC/RTP/AVP, FEC/vat, FEC/TCP, and so on?
> > >
> > > -- we'd just  have to insert a note in the registry instructing 
> > > ourselves to do it -- but we can't think of any other registries

> > > that behave this way.

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sat, 2 Oct 2010 04:34:55 -0700

Hi David,

> From: David Harrington [mailto:[email-masked]]
> Sent: Saturday, October 02, 2010 12:53 AM
> To: Ali C. Begen (abegen); [email-masked]; 'TSV Dir'
> Subject: RE: [Fecframe] [IANA #394228] RE: LastCall:<draft-ietf-fecframe-sdp-elements-08.txt> (SessionDescriptionProtocol

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

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

-acbegen

PS tsv-dir emails seem to be bouncing since I am not a member, but keeping their address in the to list just in case the moderator allows these emails.

---

From: Colin Perkins <[email-masked]>
Date: Wed, 6 Oct 2010 09:16:33 +0100

Hi,

On 2 Oct 2010, at 12:34, Ali C. Begen (abegen) wrote:
>> Subject: RE: [Fecframe] [IANA #394228] RE: LastCall:<draft-ietf- 
>> fecframe-sdp-elements-08.txt> (SessionDescriptionProtocol
>> 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.
>
>> 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.
>
> I hope my answer above answers all these questions. FEC schemes are  
> identified by their encoding IDs not protocol identifiers.
>
> 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/

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 6 Oct 2010 11:11:54 -0700

> From: Colin Perkins [mailto:[email-masked]]
> Sent: Wednesday, October 06, 2010 4:17 PM
> To: Ali C. Begen (abegen)
> Cc: David Harrington; [email-masked]; TSV Dir; [email-masked]; [email-masked]

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