Subject: [Rmt] [[email-masked]: ]

From: "'Lorenzo Vicisano'" <[email-masked]>
Date: Mon, 8 Nov 2004 10:31:09 -0800

Dear RMTers,

In the light of the recent issues brought up by FEC ID authors and
the attempt to re-use the BEF BB in an AVT/Streaming context,
Mike luby and I have put together a proposal to revise the FEC BB
before the submission for Standard Track RFC.

The proposal is attached, comments welcome. For those who are
attending the DC IETF, I'm planning to include this on tomorrow's
agenda.

	thanks you,
	Lorenzo

Proposed revisions to FEC building block in transition from
Experimental to Proposed Standard:

(0) A primary goal is to update the FEC-BB in a backward-compatible
way. It is possible that changes will need to be made to dependent
specifications, however it is desirable that the already defined
protocols have an unmodified behavior "on the wire".

(1) A Fully-Specified Encoding ID should fully and explicitly describe
the encoder and decoder, the FEC OTI, the FEC Payload ID(s), the
algorithm for how object is partitioned into source blocks (for object
delivery), exactly which bits are placed into payloads of packets. The
encoder needs to be completely specified to the point that there are
no ambiguities (to ensure inoperability for decoders using different
encoder implementations.) There should be at least enough description
of the decoder to understand how decoding generally operates, although
the requirements on the encoder are much higher (in terms of
specificity), as there may be different implementations of decoders
and some implementations may decide to skip certain steps or not fully
decode to reduce complexity, etc. For object delivery or streaming
there should be enough information in the FEC OTI and FEC Payload ID
to allow a decoder to fully understand and receive the object/stream.

(2) General descriptions that may be applicable to multiple FEC
Encoding IDs, like suggested algorithms for how to partition an object
into multiple source blocks, can be put into the FEC building block
(for example, the object partitioning algorithm currently described in
FLUTE).

(3) The FEC OTI must be more explicitly described than the vague
terminology used now, i.e., explicit parameter names and what there
values mean. Some help from AVT/SDP experts on exactly how to do this
would be highly beneficial.  A nice goal would be to be coherent with
the names: ie. if 2 names refer to the same concept in 2 different FEC
OTIs, then they should be the same. A way to achieve this would be
IANA registration, but that could be an overkill.  It should be made
more explicit that the FEC Encoding ID and FEC Instance ID (if
applicable) are required parts of the FEC OTI.

(4) Emphasize more than now that payload may contain more than one
encoding symbol, and the ESI identifies how all the encoding symobls
in the packet are generated.  This is already in the FEC building
block, but seems to be missed by most people reading it (so there is
no backward compatibility issue, it is already there.)

(5a) Add the following: If a FEC Encoding ID defines a systematic code
(encoding symbols = source symbols + repair symbols) then it may
define two different FEC Payload IDs, one for source packets carrying
source symbols and a different one for repair packets carrying repair
symbols.  In this case, it is the responsibility of the upper layer
protocols to distinguish source packets from repair packets, i.e.,
this is out of band of the FEC building block. (Just like it is now
the responsibility of the upper layer protocols to distinguish packets
for different objects/streams). 

(5b) In conjunction with (5a), it is suggested to use one of the two
reserved bits in the LCT header to indicate whether the packet is a
source of repair packet if a systematic FEC Encoding ID with two
different FEC Payload IDs is used.  This will also allow ALC and FLUTE
to use this same bit for the same purpose.  (For RTP, it turns out
that the payload type can be used to distinguish between the two types
of packets.)

(6) Consider reserving part (half?) of the FEC Encoding IDs for future
use, looking forward to dynamic allocation of FEC Encoding IDs if we
start running out of FEC Encoding IDs.

(7) Explicitly allow FEC Encoding IDs for streaming, or dual use
(object + streaming), although exactly how this would work and exactly
what part of this work would be in AVT and in RMT is still up for
discussion. Should at least discuss this in the meeting as this may
affect the RMT charter.

(8) Recommend leaving the semantics of the Under-Specified FEC
Encoding IDs pretty much the same as in the current FEC BB, subject to
the above changes.  In particular, the FEC Instance ID is not to be
thought of as the next level in a hierarchy, but instead only to be
thought of as being used to name an FEC Scheme that for whatever
reason (too many details or proprietary) the proposer doesn't want to
fully specify. One thing that needs to be worked out here is the
following inconsistency in the current FEC BB. The current FEC BB says
that the same FEC Encoding ID must be used if the FEC Payload ID
format is the same for an Under-Specified FEC scheme as the FEC
Payload ID for an existing FEC Encoding ID.  This suggests implicitly
that the FEC OTI doesn't have to be the same. The current FEC BB also
says that an FEC Encoding ID completely specifies the FEC Payload ID
and the FEC OTI, which means that you could not reuse the same FEC
Encoding ID for an Under-Specified scheme if the FEC Payload ID were
the same but the FEC OTI were different.  Thus, we need to resolve
this one of two ways: (1) an new Under-Specified FEC Scheme must use
an existing FEC Encoding ID if the FEC Payload ID and the FEC OTI are
exactly the same (and also say that new Under-Specified FEC Schemes
should try to use an already existing FEC Encoding ID if at all
possible); (2) an Under-Specified FEC Scheme must use an existing FEC
Encoding ID if the FEC Payload ID is exactly the same, but it can
augment the generic FEC OTI parameters defined by the Under-Specified
FEC Scheme by registering additional fields with IANA [the
registration of the fields would be Instance-specific]. If the generic
part of the FEC OTI defined by the Under-Specified FEC Encoding ID
doesn't apply to the specific scheme, then a new Instance ID + OTI
must be specified (even it the format of the FEC Payload ID is the
same).

(9) One FEC Encoding ID should be defined per RFC or section, with no
mixing between them (fully specify one, then the next, and not mixed
details of the different schemes in the same section).

(10) The FEC BB should describe exactly how new FEC Encoding IDs
should be written in recipe style, i.e., specify the different
sections of a newly specified RFC describing a new FEC Encoding ID and
what explicitly they should contain, so that the new FEC Encoding ID
specifications are as similar in style and complete and easy to
understand as possible.

_______________________________________________
Rmt mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rmt