[payload] Benjamin Kaduk's Discuss on draft-ietf-payload-flexible-fec-scheme-17: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-payload-flexible-fec-scheme-17: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-payload-flexible-fec-scheme/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I'm confused about some parts of how I'd implement this.
It's quite possible this is just my error, but I'm including this point in
the Discuss section in case it's not.  This basically relates to how
multiple recovery packets from a given FEC block get encoded and identified
on the wire, but also how to populate the source block when multiple SSRCs
are included.

In short: suppose that I have D=3 and L=2.  I should expect 5 repair
packets for the six source packets in a block; the scheme for determining
what order to generate them in and what their contents are is fairly clear
to me.  But how do I identify them on the wire?  I'm assuming that the D
and L on the wire are fixed values, since there's the possibility to only
send zero on the wire and negotiate their values out of band.  It's a
little less clear whether the "SN base" fields are expected to be the same
for all 5 recovery packets based on a given block, but if they do change
then I'm not sure how I tell whether a given recovery packet is for a row
or a column.  Is this supposed to be using the sequence number from the
outer RTP header for packet ordering, and the implicit order for row/column
FEC packets?  (It seems that in case of very bad packet loss and dynamic
L+D, the receiver could then get out of sync as to what the sequence number
is that corresponds to the start of a new batch of recovery blocks.)

I also don't see how, for the case when there are multiple SSRCs, I know
how many source packets to include from each SSRC in order to make up the
D x L source block -- since Section 6.2's discussion lumps all the "source
packets" together into a single set that get mutually xor'd, that seems to
imply that the encoding is not "do recovery for SSRC1, do recovery for
SSRC2, ..., concatenate them all".

There are perhaps some other scenarios to worry about, such as interleaved
recovery within a single block, but I'm happy to focus on the single 2-D
case for purposes of illustration.

Any insight into what I'm missing would be appreciated.


A couple other points to check on:

I'm not sure I'm following the procedures in Section 6.3.2 properly (see
COMMENT) -- is the text correct as written?

I also think there are a couple more factors worth mentioning in the
security considerations (see COMMENT).


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

It's a little odd to see so much content in Section 1.1 before we get to
requirements notation and defintions/notations.

I think I'm a bit confused about current best practices for multiplexing,
as RFC 3550 Section 5.2 says "separate audio and video streams SHOULD NOT
be carried in a single RTP session and demultiplexed based on the payload
type or SSRC fields", but we seem to be not only recommending using SSRC
for demultiplexing repair packets, but also suggesting that the FEC can
cover multiple different audio and/or video streams with different SSRCs.
I guess RFC 8108 is supposed to clarify when it's okay to use multiple
SSRCs in the same RTP session, so maybe the answer is just "3550 was overly
cautious and we don't worry about that anymore".

Section 4.2.1

      Version (V) 2 bits: This MUST be set to 2 (binary 10), as this
      specification requires all source RTP packets and all FEC repair
      packets to use RTP version 2.  The reason for this restriction is
      the first 2 bits of the FEC header contain other information (R
      and F bits) rather than recovering the RTP version field.

nit: is it better to say that the FEC mechanism does not recover this
value, rather than talking about how the first 2 bits of the FEC header are
used for something else?  (The FEC header's structure need not bear any
relation to the 12-byte RTP header, AFAICT.)

      Payload Type: The (dynamic) payload type for the FEC repair
      packets is determined through out-of-band means.  [...]

Is "(e.g., SDP)" applicable here?

      Sequence Number (SN): The sequence number follows the standard
      definition provided in [RFC3550].  definition.  Therefore it must

nit: drop separate "definition."

      multiplex multiple repair streams in an RTP session.  The repair
      streams' SSRC's CNAME SHOULD be identical to the CNAME of the
      source RTP stream(s) that this repair stream protects.  An FEC
      stream that protects multiple source RTP streams with different
      CNAME's uses the CNAME associated with the entity generating the
      FEC stream or the CNAME of the entity on whose behalf it performs
      the protection operation.  In cases when the repair stream covers
      packets from multiple source RTP streams with different CNAME
      values, any of these CNAME values MAY be used.

I'm not sure I'm parsing this properly; the penultimate sentence says that
the CNAME to use is determined by nature of the entity producing the repair
stream, but the last sentence says that there is a nondeterministic choice.

Section 4.2.2

Any reason not to include "retransmit" and "fixed block" mnemonics for the
'R' and 'F' bits?

Please include a note here that several fields (e.g., P, PT, etc.) in the
FEC header are not meant to be interpreted directly but are instead actual
FEC parity data akin to the following "payload".  (Absent such an
indication, the reader could see that these fields are "used to determine"
values when they appear to contain values directly, and get confused.)

I would suggest adding a forward-reference to Section 6 since that
describes how the Repair Payload is calculated.

Section 4.2.2.2

Should implementations set bounds on L and D that are smaller than the
maximum encodable value (255)?

If L=0, D=0, use the optional payload format parameters for L and D.

What is the behavior when those payload format parameters were not
provided?

The L=1 case seems to imply that some full packet retransmission will be used;
is it worth calling that out as a consequence of such a parameter choice?

Section 4.2.2.3

nit: The "P|X" bits in Figure 15 seem indented by one too many spaces.

Section 5.1 (all subsections)

Having the ToP values for interleaved and non-interleaved 1-D protection
presented in a different order than virtually all of the body text (that
presents non-interleaved first) is needlessly hard on the reader.

What is the interaction between rate, repair-window, and the L and D
values?  That is, if we set L and D to be large, and rate to be small, can
we end up claiming a repair window that is too small to accumulate the
necessary L*D source packets and compute recovery packets?

Section 5.2.1

   o  The value for the repair-window parameter depends on the L and D
      values and cannot be chosen arbitrarily.  More specifically, L and
      D values determine the lower limit for the repair-window size.
      The upper limit of the repair-window size does not depend on the L
      and D values.

Per my above remark, this consideration seems generally applicable and not
limited to SDP Offer/Answer.

   o  Any unknown option in the offer MUST be ignored and deleted from
      the answer.  If FEC is not desired by the receiver, it can be
      deleted from the answer.

This sounds like it is restating an existing normative requirement (in
which case a reference and descriptive, non-normative, text seems
appropriate).

Section 6.2

   o  The first 16 bits of the RTP header (16 bits).

Maybe note here that we'll actually ignore the first 2 bits?

Section 6.3.2

   2.   For the repair packet in T, compute the FEC bit string from the
        first 80 bits of the FEC header.

I'm scratching my head a bit at this.  Is this operation something other
than "take the first 80 bits of the FEC header"?  (If not, the length and
sequence number base seem to be in different places in the source packets
and FEC bit string, if I'm reading things right.)

   11.  Set the SN field in the new packet to SEQNUM.  Skip the next 16
        bits in the recovered bit string.

To be clear, we're skipping over the xor of the reconstructed length field
with the seqnum field of the source packets?

   13.  Take the next 16 bits of the recovered bit string and set the
        new variable Y to whatever unsigned integer this represents
        (assuming network order).  Convert Y to host order.  Y
        represents the length of the new packet in bytes minus 12 (for
        the fixed RTP header), i.e., the sum of the lengths of all the
        following if present: the CSRC list, header extension, RTP
        payload and RTP padding.

I don't see how this matches up with the bit string construction in Section
6.2.

Section 6.3.3

   1.  Append Y bytes to the new packet.
[...]
   5.  Append the recovered bit string (Y octets) to the new packet
       generated in Section 6.3.2.

I think a different verb than "append" should be used in step 1, perhaps
"allocate Y additional bytes for the new packet", as the text as-written
has us appending 2*Y bytes, only Y of which have a value specified.

Section 9

                                                               The main
   security considerations for the RTP packet carrying the RTP payload
   format defined within this memo are confidentiality, integrity and
   source authenticity.  Confidentiality is achieved by encrypting the
   RTP payload.  Integrity of the RTP packets is achieved through a
   suitable cryptographic integrity protection mechanism.  [...]

This phrasing of "is achieved by" implies that the mechanisms for doing so
are defined in this document, but that's not the case.  Don't we really
mean things like "Confidentiality can be provided by encrypting the RTP
payload"?

   Given that FLEX FEC enables the protection of multiple source
   streams, there exists the possibility that multiple source buffers
   may be created that may not be used.  An attacker could leverage
   unused source buffers to as a means of occupying memory in a FLEX FEC
   endpoint.  Moreover the application source data may not be perfectly
   matched with FLEX FEC source partitioning.  If this is the case,
   there is a possibility for unprotected source data if, for instance,
   the FLEX FEC implementation discards data that does not fit perfectly
   into its source processing requirements.

I don't think this text quite covers the risks when interacting with an
adversarial endpoint -- an attacker could try to advertise FEC schemes with
large D and L and/or large repair windows, that cause the receiver to
consume a lot of resources buffering packets that may be used as repair
inputs.  Endpoints need to be aware of the risk when deciding whether to
accept FEC streams, e.g., via SDP Offer/Answer.

Similarly, a network attacker could modify the recovery fields
corresponding to packet lengths (when integrity protection is not in play),
to force large allocations on the receiver.  It's fairly likely that this
doesn't even require knowing which source packet(s) will be lost, since
length is a 16-bit field and the expected input values are not likely to
have the high bit(s) set.

The need for integrity protection on the SDP Offer/Answer exchange is
probably sufficiently well-documented elsewhere that we don't need to
reiterate it here.