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

From: "Watson, Mark" <[email-masked]>
Date: Tue, 5 May 2009 16:05:17 -0700

All,

My understand/recollection is the following:

(1) The FSSI and SS-FSSI are octet strings, and the meaning of their contents is defined by the FEC Scheme
(2) Any framework-compliant CDP must be able to carry the FSSI and SS-FSSI intact, without making any assumptions in the CDP about what they might contain except that they are octet strings
(3) In SDP we would use base64 to represent these octet strings

I don't see how we can make these fields "human readable" in SDP without requiring every FEC Scheme to define an alternative human readable version of the FSSI and SS-FSSI. I think we went round this loop before.

I agree that (3) needs to be specified in the SDP draft.

Btw, with the recent introduction of RTP into the Framework and the associated definition of RTP Payload Formats for each FEC Scheme we decided (in a discussion late last year, I think), to define RTP Payload Format Parameters for the scheme-specific information that would otherwise be in the FSSI and SS-FSSI fields. These are in fact human-readable and are specified in the a=fmpt line in SDP rather than by using the a=fec-repair-flow attribute.  a=fec-repair-flow is only used in the case that the flow is signalled as UDP/FEC on the m= line rather than RTP/AVP. This too needs to be clarified in the SDP draft.

...Mark

On 4/30/09 9:44 AM, "Ali C. Begen (abegen)" <[email-masked]> wrote:

Hi Mathieu,

Inline.

> -----Original Message-----
> 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,
>
> 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.

Yup.

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

I will let Mark comment on this one. I agree with the earlier part (defining the contens of the SSI).

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

Yes, we need to make a decision.

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

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

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

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

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

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

>
> Regards,
>
>     Mathieu, Alice and Vincent
>
>
>
> Ali C. Begen (abegen) wrote:
> > 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,
> >>
> >> 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...
> >>
> >>
> >> _______________________________________________
> >> Fecframe mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/fecframe
> >>
> >>
> >
> >
> >
>
>
_______________________________________________
Fecframe mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/fecframe