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

From: [email-masked]
Date: Sun, 14 Nov 2004 19:18:46 +0200

Thanks Lorenzo & Mike - excellent initiative.

Please see some in-liners (as I am not in DC to say this myself)...

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

Sensible approach.

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

Excellent.

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

The level of specification is to enable interoperability - this must be the first point (which everyone probably is already happy with).

Is it really necessary in all cases to fully specify an encoder to achieve this? (Forgive me my ignorance - not being a FEC maestro)

(Note, I agree with most of the above paragraph - I just want to sanity check that the level of normative specification is not beyond the necessary).

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

Excellent.

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

Excellent.

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

OK. I think it's already quite clear but improving clarity is usually a good thing. Naturally a FEC spec will determine whether or not it always/sometimes/never stuffs more than one encoding symbol into a payload.

For compact no code FEC, it is logical that only one symbol per payload is used (symbol length usually selected for the expected end-to-end MTU limits). But I don't think we need to make that mandatory for all cases.

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

OK.

I believe the desired functionality is allowed already - one FEC encoding ID for source (e.g. ID=0) and one for redundant (e.g. ID=130). 

Your proposal is to add a 1/0 payload id to the FEC OTI (in addition to FEC encoding id an FEC instance id) - right?

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

Were any other options considered?

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

Makes sense, though we don't exactly have a rush of work in RMT at the moment :)

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

Great - but isn't this already allowed? I guess the new aspect is to require that FEC I-Ds explicitly state their applicability to RTP and ALC (and any limitations like "only FLUTE"). OTOH, the level of FEC specification suggested above (exactly how bits are put into packets) would force this anyway.

The FEC BB rewrite will make it's applicability to both RTP and ALC (not forgetting NORM and everything else) clear. I guess the essential issue is to ensure the "RTP RMT-FEC-BB payload wrapper" is supported in both RMT and AVT. (BTW, it's a great idea!!!)

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

It's late so I might be wrong but: (1) sounds cleaner - allowing different OTI to be use a different FEC Encoding ID. (The term "Payload ID" needs defining - if someone gets to the correct definition document first - please share the news!)

BTW I guess "an existing FEC Encoding ID" -> "an existing under specified FEC Encoding ID" would be correct (and less ambiguous)

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

This may turn out to be academic, but in the theoretical case where two codes are 95% identical, it makes very little sense to repeat the 95% part of the algorithm a second time (though copy & paste ought to avoid it introducing new bugs). In another theoretical case, where a FEC scheme is a derivative of another, and RFC which properly references an earlier RFC is better (due to less documentation overhead and consistency checking) than two fully-specified schemes. Naturally, if no such schemes exist then this is academic and one fully specified (in all detail) FEC Encoding ID per section of a standards track RFC (and I-D going for standards track) is reasonable. Any such codes?

(Note, in any case I think this should not apply to Informational and Experimental RFCs who's normal purpose are to spread information and provide some basis for interoperable testing anyway.)

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

Sounds like a good idea. It would be useful to get _all_ the authors of current FEC RFCs and I-Ds involved to sanity check that the one-size-fits-all recipe fits at least the prior work and work-in-progress.

Cheers, Rod.

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

---

From: "Michael Luby" <[email-masked]>
Date: Mon, 15 Nov 2004 20:27:55 -0800

Rod, Comments inline.  Thx for your support.
Best, Mike

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Sunday, November 14, 2004 9:19 AM
> To: [email-masked]; [email-masked]
> Subject: RE: [Rmt] [[email-masked]: ]
>
>
> The level of specification is to enable interoperability - this
> must be the first point (which everyone probably is already happy with).
>
> Is it really necessary in all cases to fully specify an encoder
> to achieve this? (Forgive me my ignorance - not being a FEC maestro)

Of course at this point we are only talking about Fully-Specified FEC
Schemes, not Under-Specified FEC Schemes.   Clearly you don't literally have
to fully explain each detail of the encoder (like data structures), but it
must be down to the level that the spec exactly describes what is carried
"on the wire", i.e., the received FEC OTI and the FEC Payload ID must fully
specify the exact encoding symbol bits carried in the payload.  This is the
same type of requirements that I understand are used for RTP.

>
> (Note, I agree with most of the above paragraph - I just want to
> sanity check that the level of normative specification is not
> beyond the necessary).
>
> OK. I think it's already quite clear but improving clarity is
> usually a good thing. Naturally a FEC spec will determine whether
> or not it always/sometimes/never stuffs more than one encoding
> symbol into a payload.
>
> For compact no code FEC, it is logical that only one symbol per
> payload is used (symbol length usually selected for the expected
> end-to-end MTU limits). But I don't think we need to make that
> mandatory for all cases.
>
> I believe the desired functionality is allowed already - one FEC
> encoding ID for source (e.g. ID=0) and one for redundant (e.g. ID=130).

Actually, it is not at all clear that what you suggest is a legitimate usage
based on the current FEC building block.  I don't think it explicitly says
one way or the other that you can or cannot use different FEC Encoding IDs
to deliver the same object (which is the example you gave above).  I think
it even says explicitly somewhere (but perhaps it is only in LCT or ALC or
FLUTE, I would need to check carefully) that you can only use  one FEC
Encoding ID per object, i.e., you explicitly cannot use two FEC Encoding IDs
for hte same object.  The proposal is to make the use of different FEC
Payload IDs explicitly legitimate in the umbrella of one FEC Encoding ID,
i.e., one FEC Encoding ID will have two possible FEC Payload ID formats, one
for source and one for repair.  The proposal still would not allow using two
FEC Encoding IDs for the delivery of one object.

>
> Your proposal is to add a 1/0 payload id to the FEC OTI (in
> addition to FEC encoding id an FEC instance id) - right?

It would not be in the FEC OTI (which is generally carried out of band).  It
would simply define two FEC Payload IDs, one for source and one for repair
packets.  It would be up to higher layer protocols to distinguish source
from repair packets, and this would determine the actual FEC Payload ID used
in the packet.

> Were any other options considered?

Yes, but this is the one way of doing this that would allow backwards
compatibility, since any existing FEC Encoding ID only uses one FEC Payload
ID, and thus this bit would be set to 0.  Thus, any current implementations
would have this reserved bit set to zero, and it would only be for new FEC
Encoding IDs that defined two different FEC Payload IDs for source and
repair packets that this bit would ever be set to 1 (for repair packets).

> Great - but isn't this already allowed? I guess the new aspect is
> to require that FEC I-Ds explicitly state their applicability to
> RTP and ALC (and any limitations like "only FLUTE"). OTOH, the
> level of FEC specification suggested above (exactly how bits are
> put into packets) would force this anyway.

The RMT wg charter does not currently include streaming, and thus any
current references to streaming are informational only, not normative.

>
> The FEC BB rewrite will make it's applicability to both RTP and
> ALC (not forgetting NORM and everything else) clear. I guess the
> essential issue is to ensure the "RTP RMT-FEC-BB payload wrapper"
> is supported in both RMT and AVT. (BTW, it's a great idea!!!)
>
> It's late so I might be wrong but: (1) sounds cleaner - allowing
> different OTI to be use a different FEC Encoding ID. (The term
> "Payload ID" needs defining - if someone gets to the correct
> definition document first - please share the news!)

Lorenzo and I discussed this point, and I actually prefer (1) also, but
Lorenzo pointed out (rightly so) that this might mean little sharing of
Under-Specified FEC Encoding IDs by FEC schemes.  However, if we could try
to go route (1) and see if it works and then fall back to (2) if it doesn't,
I would like that, as you are right (1) is definitely cleaner.

>
> BTW I guess "an existing FEC Encoding ID" -> "an existing under
> specified FEC Encoding ID" would be correct (and less ambiguous)

Yes.

> This may turn out to be academic, but in the theoretical case
> where two codes are 95% identical, it makes very little sense to
> repeat the 95% part of the algorithm a second time (though copy &
> paste ought to avoid it introducing new bugs). In another
> theoretical case, where a FEC scheme is a derivative of another,
> and RFC which properly references an earlier RFC is better (due
> to less documentation overhead and consistency checking) than two
> fully-specified schemes. Naturally, if no such schemes exist then
> this is academic and one fully specified (in all detail) FEC
> Encoding ID per section of a standards track RFC (and I-D going
> for standards track) is reasonable. Any such codes?

This is a good point, and I'm not sure if it is too academic or not.  The
intent of course is to not have completely different FEC schemes defined in
an intermixed way in the same RFC (and there has been some instances of
this, of which I think I am also guilty in the past).  Properly organized
descriptions of FEC schemes should make the docs more readable...

>
> (Note, in any case I think this should not apply to Informational
> and Experimental RFCs who's normal purpose are to spread
> information and provide some basis for interoperable testing anyway.)
>
> Sounds like a good idea. It would be useful to get _all_ the
> authors of current FEC RFCs and I-Ds involved to sanity check
> that the one-size-fits-all recipe fits at least the prior work
> and work-in-progress.
>
>
> Cheers, Rod.
>