draft-ietf-rmt-bb-fec-raptor-object

"Mark Watson" <[email protected]>
Newsgroups gmane.ietf.rmt
Message-ID <[email protected]>
All,

 

I was asked at the RMT session on Monday to summarise the differences
between the Raptor FEC schemes defined in 3GPP TS26.346 and proposed in
draft-ietf-rmt-bb-fec-raptor-object-01.

 

Things in the 3GPP specification which are not in the Internet Draft:

1)     3GPP includes Raptor FEC Schemes for both object delivery and
streaming and a general framework for application of FEC to streaming.
Whilst we have separately proposed such a streaming framework to TSVWG
in IETF, it is not presently in scope of RMT.

2)     3GPP includes additions to FLUTE for transport of FEC
Scheme-specific information whereas in IETF we are discussing adding
this to FLUTE itself

3)     (the obvious one) 3GPP includes lots of other things for MBMS
which are nothing to do with FEC

 

Things in the Internet Draft which are not in the 3GPP specification:

1)     The Internet Draft correctly follows the proposed FEC Scheme
specification format from the new FEC Building Block, opening the
possibility to use the FEC Scheme with any Content Delivery Protocol,
not just FLUTE

2)     The Internet Draft includes Security Consideration which are not
included in the 3GPP specification

3)     The Internet Draft includes IANA Consideration which register a
new FEC Encoding ID value

 

The actual FEC encoding/decoding algorithms are defined in Sections 5.5
to 5.8 of the Internet Draft and Sections B.5 to B.8 of the 3GPP
Technical Specification. The material in these parts of the two
specifications is technically identical.

 

Additionally, the material on Object Delivery in 5.4 of the Internet
Draft is the same as the corresponding section B.3 of the 3GPP TS.

 

In the remainder of the areas where there is overlap, then although the
material is technically equivalent, the format/description is not. This
is the material which most needs review in IETF and includes the
definition of the Object Transmission Information formats, FEC Payload
ID etc. according to the FEC Building Block. If there are changes needed
in these sections then I suggest we start by trying to make them
backwards compatible with the 3GPP specification.

 

To properly define the FEC Scheme in a way which follows the FEC BB and
thus allows use of the code with any Content Delivery Protocol we need a
standards track document as previously agreed. I think actually it would
not be appropriate to reference material from 3GPP in a Standards Track
document, especially since the material which could be referenced is
just the core encoding/decoding algorithm.

 

Thus, I'd like to encourage everyone to review the other parts of the
draft - essentially everything except section 5 - and hopefully we can
shortly move to WG last call.

 

Regards,

 

Mark

_______________________________________________
Rmt mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/rmt
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.