Subject: [FECFRAME-PROTO] Opacity of the scheme-specific information

From: "Ali Begen \(abegen\)" <[email-masked]>
Date: Mon, 24 Sep 2007 07:35:57 -0700

Hi all,

I am trying to identify the pros and cons of using opaque information
for signaling the fec-scheme-specific info. I am aware of that RMT
adopted the same approach for object transmission information and if a
receiver is not compatible with a particular FEC scheme, then it does
not have to parse that information. 

Yet, I believe it is still important to make a strong case why we put
that information in an opaque form rather than in a human-readable form?

I checked the RFC 5052, however, could not find much detail on this. One
of my concerns is that can the opacity lead to some sort of abusing? 

Any one with a prior experience on using opaque stuff in a protocol
header? Comments?

-acbegen

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

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 24 Sep 2007 11:41:32 -0400

Modern Codecs tend to use a lot of opaque information, which bugs me,  
but we are not going to change that.

Most streaming codecs make the SDP file from the presented encoded  
data to stream. Encoded information might be all sorts of things,  
aspect ratios, GOP structure, audio bit rates, stereo vs mono, etc.  
If the streamer gets something wrong, it is very hard to fix it in  
the SDP file, even if you know what it should be, because it is  
opaque. This has caused me considerable pain in the past.

I am sure that it more efficient to base 64 encode a 500 character  
string rather than send it in Ascii, but
this seems a strange efficiency argument when you are talking about a  
SDP file (sent once) for a multiple megabit per second video stream.

One argument that I haven't heard but might be there is that with the  
opaque blob you don't have to document what you are doing. It may  
just be a convenient rug to sweep things under.

Regards
Marshall

---

From: "Ali Begen \(abegen\)" <[email-masked]>
Date: Mon, 24 Sep 2007 08:55:22 -0700

Hi Marshall,

See inline. 

> Modern Codecs tend to use a lot of opaque information, which 
> bugs me, but we are not going to change that.
> 
> Most streaming codecs make the SDP file from the presented 
> encoded data to stream. Encoded information might be all 
> sorts of things, aspect ratios, GOP structure, audio bit 
> rates, stereo vs mono, etc.  
> If the streamer gets something wrong, it is very hard to fix 
> it in the SDP file, even if you know what it should be, 
> because it is opaque. This has caused me considerable pain in 
> the past.

I agree, this is a concern. Actually, with the deployment of middle
boxes that do some processing on the video streams flowing through them,
this is indeed a problem. If the info is in Ascii, it can be repaired
somwhere along the path.
 
> I am sure that it more efficient to base 64 encode a 500 
> character string rather than send it in Ascii, but this seems 
> a strange efficiency argument when you are talking about a 

Yes, the coding efficiency for opaque SDP should not be the reason we
are doing this.

> One argument that I haven't heard but might be there is that 
> with the opaque blob you don't have to document what you are 
> doing. It may just be a convenient rug to sweep things under.

This is what I meant with "abusing," and is our primary concern. I have
not been in IETF to observe this problem and you are saying that you
have not heard so far, but that does not mean that no one is doing it. 

Any more comments?

-acbegen

> > I checked the RFC 5052, however, could not find much detail 
> on this. 
> > One of my concerns is that can the opacity lead to some sort of 
> > abusing?
> >

---

From: Mark Watson <[email-masked]>
Date: Mon, 24 Sep 2007 09:46:03 -0700

All,

"Opaque" was intended to mean that the information carried is not
_logically_ visible to the carrying protocol. That is, the carrying protocol
does not place requirements on what can or should be carried, or make
assumptions about what is there, and it delivers the information intact to
the responsible component at the receiving end.

"Opaque" was not intended to mean that the information is deliberately
obfuscated.

Also, what we are defining here is specification responsibilities, not
implementation architecture: it is the responsibility of the FEC Scheme
specification to define the contents of the Scheme-specific information and
the responsibility of the CDP specification to specify how it is carried in
a protocol. The two must be decoupled so that CDPs are not
FEC-scheme-specific and vice versa. This says nothing about what
implementations are allowed to do with information they find in packets: you
can implement FEC-scheme-specific functionality wherever you like.

The reason for using base64 is that the information is defined as a sequence
of octets and you cannot carry raw octets in SDP. We could, alternatively,
require that the information is ASCII and then it can be carried directly
(with certain restrictions). When I said above that the protocol could not
place requirements on what can be carried, this means a *particular*
protocol - the FEC Framework itself can place whatever requirements we like.

A reason for allowing arbitrary octets is that it allows FEC Schemes to
define efficient (binary) encodings, which can then be used with other CDPs
that are themselves binary coded.

So, what it comes down to is that if we ask FEC Schemes to define a
text-based encoding (which has the advantages implied by the mails below),
then we restrict the set of possible CDPs supported by the framework to
those within which text-based encoding is acceptable.

I would prefer that we not make this restriction. It is, after all, no
harder to write code which unpacks a base-64 encoded BLOB than to parse a
sequence of text "name=value;" pairs.

Regards,

Mark

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 24 Sep 2007 13:31:48 -0400

Are we going to require instantiations to publish pseudo-code to  
describe how to read the opaque parts ?
(AVT does not.)

Regards
Marshall

---

From: "Michael Bany" <[email-masked]>
Date: Mon, 24 Sep 2007 12:41:31 -0500

I wonder if this would cause problems with proprietary schemes.

Mike

-----Original Message-----
From: Marshall Eubanks [mailto:[email-masked]] 
Sent: Monday, September 24, 2007 12:32 PM
To: Mark Watson
Cc: [email-masked]
Subject: Re: [FECFRAME-PROTO] Opacity of the scheme-specific information

Regards
Marshall

---

From: Mark Watson <[email-masked]>
Date: Mon, 24 Sep 2007 10:41:20 -0700

FEC schemes must describe the encoding format of the data in the usual, if
that's what you mean. I don't think pseudo-code is necessary.

...Mark

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 24 Sep 2007 14:06:53 -0400

That is a real concern. I suspect we can't mandate any such thing,  
for non fully specified schemes.

I would say that a fully specified scheme should have this information.

Regards
Marshall

---

From: "Ali Begen \(abegen\)" <[email-masked]>
Date: Mon, 24 Sep 2007 14:16:38 -0700

Hi Mark,

Which ones fall out of the set of "CDPs to those within which text-based
encoding is acceptable"? Are there many that do not allow text-baed
encoding? Do we have an approximate number? Of course, if there are many
out there, we should leave it as is.

-acbegen

> From: Mark Watson [mailto:[email-masked]] 
> Sent: Monday, September 24, 2007 9:46 AM
> To: Ali Begen (abegen); Marshall Eubanks
> "Opaque" was intended to mean that the information carried is 
> not _logically_ visible to the carrying protocol. That is, 
> the carrying protocol does not place requirements on what can 
> or should be carried, or make assumptions about what is 
> there, and it delivers the information intact to the 
> responsible component at the receiving end.
> 
> "Opaque" was not intended to mean that the information is 
> deliberately obfuscated.
> 
> Also, what we are defining here is specification 
> responsibilities, not implementation architecture: it is the 
> responsibility of the FEC Scheme specification to define the 
> contents of the Scheme-specific information and the 
> responsibility of the CDP specification to specify how it is 
> carried in a protocol. The two must be decoupled so that CDPs 
> are not FEC-scheme-specific and vice versa. This says nothing 
> about what implementations are allowed to do with information 
> they find in packets: you can implement FEC-scheme-specific 
> functionality wherever you like.
> 
> The reason for using base64 is that the information is 
> defined as a sequence of octets and you cannot carry raw 
> octets in SDP. We could, alternatively, require that the 
> information is ASCII and then it can be carried directly 
> (with certain restrictions). When I said above that the 
> protocol could not place requirements on what can be carried, 
> this means a *particular* protocol - the FEC Framework itself 
> can place whatever requirements we like.
> 
> A reason for allowing arbitrary octets is that it allows FEC 
> Schemes to define efficient (binary) encodings, which can 
> then be used with other CDPs that are themselves binary coded.
> 
> So, what it comes down to is that if we ask FEC Schemes to 
> define a text-based encoding (which has the advantages 
> implied by the mails below), then we restrict the set of 
> possible CDPs supported by the framework to those within 
> which text-based encoding is acceptable.
> 
> I would prefer that we not make this restriction. It is, 
> after all, no harder to write code which unpacks a base-64 
> encoded BLOB than to parse a sequence of text "name=value;" pairs.
> 
> Regards,
> 
> Mark
> 
> 
> > boxes that do some processing on the video streams flowing through 
> > them, this is indeed a problem. If the info is in Ascii, it can be 
> > repaired somwhere along the path.
> >  
> >> string rather than send it in Ascii, but this seems a strange 
> >> efficiency argument when you are talking about a SDP file 
> (sent once) 
> >> for a multiple megabit per second video stream.
> > 
> > This is what I meant with "abusing," and is our primary concern. I 
> > have not been in IETF to observe this problem and you are 
> saying that 
> > you have not heard so far, but that does not mean that no 
> one is doing it.
> > 
> > Any more comments?
> > 
> > -acbegen
> > 
> > 
> >> Regards
> >> Marshall
> >> 
> >> 
> >>> that information in an opaque form rather than in a 
> human-readable 
> >>> form?
> >>>

---

From: Mark Watson <[email-masked]>
Date: Mon, 24 Sep 2007 23:48:34 -0700

Well, there are none of either kind yet ;-) The FEC Framework will identify
what features an FECFRAME Content Delievery Protocol needs to support to
work with the framework.

The intention is for us in FECFRAME to define a single Content Delivery
Protocol, which can be thought of as the first of many (or at least
several).

So, the restriction is on future protocols that might want to make use of
our framework. If we restrict to text-based protocols, then people who work
in an environment in which this is not appropriate would not be able to make
use of the framework and this would diminish the value of the work. We could
imagine that people in various different standards groups, as well as for
non-standard applications might find FECFRANE useful and in some contexts
binary protocols are preferred (though often, it seems, for non-technical
reasons).

Another alternative of asking FEC Schemes to specify both a text and binary
version of the scheme-specific information might be overkill.

...Mark

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 25 Sep 2007 06:56:19 -0400

I have no trouble with using binary. I just think that, for fully  
specified schemes, they have
to be fairly clear what the binary means. For the other schemes, I  
realize that we
cannot enforce that.

Marshall

---

From: "Rajiv Asati \(rajiva\)" <[email-masked]>
Date: Tue, 25 Sep 2007 08:23:21 -0400

I agree with Mark. 

1) It seems optimal to define whatever CDP protocol(s) without assuming
a particular FEC scheme specifics. In other words,  a given CDP should
be able to signal "whatever" FEC scheme info.

2) Additionally, it seems quite beneficial to construct the "FEC
specific information" independent of CDP. So, a particular FEC-scheme
could construct and structure its information that can be carried by any
CDP. 

This is where the building block approach becomes beneficial. How is one
building block constructed is independent of the next building block. We
should also consider using something similar to TLVs (type length
value). 

	Of course, the (type of) TLVs may be 
	leveraged by more than one FEC-scheme,
	but they don't have to be.

3) I don't think that sending this info in ASCII is optimal either.
While, human-readablity is desired, it is orthagonal to how the
FEC-specific information is carried by the CDP. 

	An implementation could include a proper
	conversion utility (say) to display the
	info in human-readable form.

4) I am of opinion that the spec should not limit to base64 encoding,
since this will also limit the reusing of existing protocol as CDP. 

Cheers,
Rajiv

> Sent: Monday, September 24, 2007 12:46 PM
> defined as a sequence
> protocol could not
> Schemes to

---

From: "Rajiv Asati \(rajiva\)" <[email-masked]>
Date: Tue, 25 Sep 2007 09:53:18 -0400

Hi Marshall,

I agree. 

Perhaps, this could be the requirement for the draft to become an I-D.

Cheers,
Rajiv

> Sent: Tuesday, September 25, 2007 6:56 AM
> To: Mark Watson
> > use of the framework and this would diminish the value of 
> the work.  
> > We could
> >> Which ones fall out of the set of "CDPs to those within 
> which text- 
> >> based