Subject: [Fecframe] Remark on the textual representation of FSSI fields

From: Mathieu Cunche <[email-masked]>
Date: Wed, 29 Apr 2009 14:09:51 +0200

Hello everybody,

We have a remark on the the way the  FSSI (FEC Scheme-Specific
Information) and the SS-FSSI (Sender-Side FSSI) binary fields
are converted into a character string for SDP.
In fact we haven't found any specification in the various
FECFRAME I-Ds on the way this conversion should be done.

>From RFC4566 "Session Description Protocol", p.33:
    "Encoding considerations:
    SDP files are primarily UTF-8 format text. The "a=charset:"
    attribute may be used to signal the presence of other
    character sets in certain parts of an SDP file (see
    Section 6 of RFC 4566
    <http://tools.ietf.org/html/rfc4566#section-6>). Arbitrary
    binary content cannot be directly represented in SDP."

We are typically in the case where we need a textual encoding
of the binary SS-FSSI/FSSI "octet string".

In the SDP example provided in draft-ietf-fecframe-raptor-00
(section 10) it seems that the encoding used is Base64. However
this is never explicitly said (!), neither in this I-D nor in
any other I-D (see extracts at the end of the email).
-----------
    [...]
    a=fec-repair-flow: scheme-id=0; ss-fssi=5hu=
------------
(BTW: the above SDP description is erroneous, since SS-FSSI
 is never defined elsewhere in this I-D and on the opposite
 the FSSI is missing)

Base64 seems to be the best solution (more compact than
an hexadecimal string). Should this encoding be definitively
adopted? And in this case, where should it be specified?

Our feeling is that:
- it should be clarified in each FEC scheme document (as
  is the case with RFC 5170/4.2.4.2 (LDPC) and
  RFC 5510/4.2.4.2 (Reed-Solomon)), when a textual encoding
  is needed for the "octet string";

- it should be specified in the sdp-elements I-D, section 3.3.
  as well.

Regards,

    Mathieu, Alice and Vincent

NB: here are the I-D extracts that mention SS-FSSI and FSSI:

------------

* SDP Elements for FEC Framework (draft-ietf-fecframe-sdp-elements-02):

    - page 6: "The variable-length opaque SS-FSSI and FSSI containers
    transmit the information in the form of an octet string. The FEC
    schemes define the structure of this octet string, which may contain
    multiple distinct elements."

    - page 10: " The OPTIONAL parameters 'ss-fssi' and 'fssi' are opaque
    containers to convey the FEC-Scheme-Specific Information (FSSI) that
    includes the information that is specific to the FEC scheme used by
    the CDP and is necessary for proper FEC encoding and decoding
    operations.  The FSSI required only by the sender (called
    Sender-Side FSSI) MUST be communicated in the container specified by
    the parameter 'ss-fssi'. Any other FSSI MUST be communicated in the
    container specified by the parameter 'fssi'.  In both containers,
    FSSI is transmitted in the form of an octet string.  The FEC schemes
    define the structure of this octet string, which MAY contain
    multiple distinct elements.  If the FEC scheme does not require any
    specific information, the 'ss-fssi' and 'fssi' parameters MAY be
    null and ignored."

MC => this text should be fixed since "transmitting the FSSI in the form
      of an octet string" is not possible.

* Methods to convey FEC Framework Configuration Information
(draft-ietf-fecframe-config-signaling-01.txt)

    - page 5: "Additionally, the encoding format for each FEC Framework
    configuration parameter must be defined in terms of a sequence of
    octets that can be embedded within the payload of the signaling
    protocol message(s).  The length of the encoding format MUST either
    be fixed, or derived by examining the encoded octets themselves.
    For example, the initial octets may include some kind of length
    indication. [...]The reader may refer to the SDP elements document
    [FECSDP], which describes the usage of 'SDP' encoding format as an
    example encoding format for FEC framework configuration information."

MC => with Base64 encoding, there is no need to add any "initial octet
      to include a length indication". It's the goal of the final "="
      or "==" characters.

* Raptor FEC Schemes for FECFRAME (draft-ietf-fecframe-raptor-00)

    - page 8: "The scheme-specific elements of the FEC Framework
    Configuration information for this scheme are as follows:
    Maximum Source Block Length  A non-negative integer less than 213,
    in units of symbols
    Encoding Symbol Size  A non-negative integer less than 216, in
    units of bytes
    An encoding format for this information in a 4 octet field is
    defined as follows:

                                1                   2                   3
            0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |       Symbol Size (T)         |   Max. Source Block Length    |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 1: FEC Scheme Specific Information

MC => the "encoding format" here refers to the binary encoding, not
      the final encoding to be used when this binary encoding must
      be carried in SDP or any textual representation.

* And of course, we need to fix our Reed-Solomon I-D too...

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 29 Apr 2009 14:12:35 -0700

Hi Mathieu,

Thanks for bringing this up. My feeling is that the FEC scheme drafts should define the content of the FSSI information (i.e., what needs to go in there) but they do not normally need to define how the FSSI should be encoded in the SDP since FEC schemes may use other ways to convey the configuration information. However, if a scheme uses RTP, we clearly need the SDP encodings for that scheme as RTP will imply using SDP.

For the encoding in SDP, we could use base64 as the default format. However, this has the disadvantage of not being human-readable. When we consider RTCP instrumentation in the middle boxes in the network, the opaque data is not a good idea, either. Just because it saves some bits won't make it an ideal encoding format. So, personally I prefer ascii. And when I look at most other formatting parameters (like the ones for RTP), they are all ascii.

There are certain semantics that are not scheme specific, and they should be in ascii format in the SDP (like a=repair-window) anyway.

We had a similar discussion in 2007. Look at the archives here:
http://www.ietf.org/mail-archive/web/fecframe-proto/current/mail7.html

Comments?

-acbegen

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Mathieu Cunche
> Sent: Wednesday, April 29, 2009 5:10 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Fecframe] Remark on the textual representation of 
> FSSI fields
> 
> Hello everybody,
> 
>                                 1                   2         
>           3
> _______________________________________________
> Fecframe mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/fecframe
>

---

From: Mathieu Cunche <[email-masked]>
Date: Thu, 30 Apr 2009 16:45:15 +0200

Hi Ali,

Thanks for the link. To summarize this 2007 discussion, there are
basically two issues:

- Does the FSSI need to be encoded into human-readable form or not?

	Compactness is not an issue. We agree.
	Having a human readable encoding can ease debugging. We agree.
	SDP is only one possible way of carrying the FSSI, and we
	must not restrict the kind of signaling mechanism. We agree.

- Where should this encoding be specified?

	Quoting Mark:
	"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."
	However, there is no clear conclusion on this point.

(Don't hesitate to correct us if we missed/misunderstood something)

In any case, the issue must be fixed, since:
- arbitrary binary content (like FSSI) cannot be directly represented
  in SDP
- current I-Ds already use different assumptions
- none of them specifies what should be done, worse they contradict
  one another
More specifically:
	SDP elem => "octet string", without precision, and examples
		are provided: ss-fssi=1Q2A3Z; fssi=4W5S6X
	raptor => not specified, but the example: ss-fssi=5hu=
		suggests Base64 is used

Concerning point 1, we have several possibilities:
- use base64: its compactness is not an asset in this case, but
  it remains simple and well known.

- use hexadecimal: it's much more user friendly than base64
  encoding, especially with a structured FSSI.

- use an ASCII encoding of the whole FSSI value: for instance,
  with an FSSI composed of two 16bit fields, containing 10 and 8
  respectively, the whole FSSI value is:
	00001010 00001000 (bin) = 2568 (dec), encoded as the ASCII
	string "fssi=2568"
  This is a bit tricky however!

- another ASCII alternative is to carry the ASCII string for each
  FSSI internal field, separated by a comma (for instance).
  With the above example: "fssi=10,8"
  Simple, human readable, but no longer opaque and rather tricky!

One open question: does SDP have any mechanism to specify, within
the SDP file itself, the encoding used for the binary->textual
transformation. Eg., a way to say that what follows is in hexadecimal
or is base64 encoded? If this is permitted, this encoding can be
left unspecified with SDP. In case of another protocol, an explicit
rule can be defined if need be.

Concerning point 2, our feeling is that the encoding of the FSSI
should be defined in the SDP Element, i.e., where it is used.

Regards,

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 30 Apr 2009 09:44:40 -0700

Hi Mathieu,

Inline.

> From: Mathieu Cunche [mailto:[email-masked]] 
> Sent: Thursday, April 30, 2009 7:45 AM
> To: Ali C. Begen (abegen)
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Fecframe] Remark on the textual representation 
> of FSSI fields
> 
> Hi Ali,
> 

Yup.
 
> 	However, there is no clear conclusion on this point.

I will let Mark comment on this one. I agree with the earlier part (defining the contens of the SSI).
 
> - none of them specifies what should be done, worse they contradict

Yes, we need to make a decision.

>   Simple, human readable, but no longer opaque and rather tricky!

We need input from the WG on this as it will apply to almost all drafts.

> rule can be defined if need be.

I'd think this is possible based on the text you cited yesterday, but I am not sure.

> should be defined in the SDP Element, i.e., where it is used.

Agree, I will update the draft once we reach a consensus here. To do that, we need to hear from FECframe folks. And this discussion is really overdue.

BR,
-acbegen

> > Thanks for bringing this up. My feeling is that the FEC 
> scheme drafts should define the content of the FSSI 
> information (i.e., what needs to go in there) but they do not 
> normally need to define how the FSSI should be encoded in the 
> SDP since FEC schemes may use other ways to convey the 
> configuration information. However, if a scheme uses RTP, we 
> clearly need the SDP encodings for that scheme as RTP will 
> imply using SDP.
> >
> > For the encoding in SDP, we could use base64 as the default 
> format. However, this has the disadvantage of not being 
> human-readable. When we consider RTCP instrumentation in the 
> middle boxes in the network, the opaque data is not a good 
> idea, either. Just because it saves some bits won't make it 
> an ideal encoding format. So, personally I prefer ascii. And 
> when I look at most other formatting parameters (like the 
> ones for RTP), they are all ascii.
> >
> > There are certain semantics that are not scheme specific, 
> and they should be in ascii format in the SDP (like 
> a=repair-window) anyway.
> >