Subject: [AVT] Comments on draft-ietf-avt-ulp-11

From: Magnus Westerlund <[email-masked]>
Date: Wed, 20 Jul 2005 11:16:30 +0200

Hi Adam,

I have reviewed the updated draft and have a couple of comments. 
Unfortunately I don't think the draft is ready for publication, but it 
is getting close. I will also send comments on the FEC grouping draft to 
MMUSIC.

1. Section 7.3, SSRC:

    SSRC: The SSRC value will generally be the same as the SSRC value of
    the media stream it protects.

I think generally here is a bit unclear. Based on what is written 
elsewhere in the draft this is in fact a SHALL. So I would suggest that 
you change the sentence to:

    SSRC: The SSRC value SHALL be the same as the SSRC value of
    the media stream it protects.

2. Section 10: The examples:

I think the mask listing could be improved in the examples. Instead of

mask:      61440 [with Packet 8, 9, 10, and 11 marked]

I think one should discuss the bit level:

mask:      61440 [with bits (Pkt Seq nr.) 1(8), 2(9), (3)10, and 4(11) 
marked]

3. Section 11. I think we need to split out the congestion related 
discussion into its own Congestion Control section. There is also need 
to add some text here regarding RTP and profiles.

Congestion Control

    Another issue with the use of FEC is its impact on network
    congestion. In many situations, the packet loss in the network is
    induced by congestions. In such scenarios, adding FEC when
    encountering increasing network losses should be avoided. If it is
    used on a widespread basis, this can result in increased congestion
    and eventual congestion collapse. The applications may include
    stronger protections while at the same time reduce the bandwidth for
    the payload packets. In any event, implementations MUST NOT
    substantially increase the total amount of bandwidth in use
    (including the payload and the FEC) as network losses increase.

    The general congestion control considerations for transporting RTP
    data apply, see RTP [3] and any applicable RTP profile like AVP [9].
    An additional requirement if best-effort service is being used is:
    users of this payload format MUST monitor packet loss to ensure that
    the packet loss rate is within acceptable parameters.  Packet loss is
    considered acceptable if a TCP flow across the same network path, and
    experiencing the same network conditions, would achieve an average
    throughput, measured on a reasonable timescale, that is not less than
    the RTP flow is achieving.  This condition can be satisfied by
    implementing congestion control mechanisms to adapt the transmission
    rate (or the number of layers subscribed for a layered multicast
    session), or by arranging for a receiver to leave the session if the
    loss rate is unacceptably high.

4. The MIME registration must be updated to reflect what has been agreed 
so far in discussions with the MIME people. I have below one updated 
registration. Please note that I have added the rate parameter as it is 
now needed.

12. MIME Registrations

    Four new MIME sub-types as described in this section are to be
    registered with IANA. This registration is done using the
    template defined in [freed] and following RFC 3555 [RFC3555].

12.1. Registration of audio/ulpfec

    MIME media type name: audio

    MIME subtype name: ulpfec

    Required parameters: none

    Rate: The RTP timestamp rate which is used to mark the time of
    transmission of the FEC packet in separate stream. In cases it is
    sent as redundant data to another stream the rate SHALL be the same
    as the primary encoding it is used to protect. When used in a
    separate stream the rate SHALL be larger than 1000 Hz to provide
    sufficient resolution to RTCP operations. The selected rate MAY be
    any value above 1000 Hz but is RECOMMENDED to match the rate of the
    media this stream protects.

    Optional parameters: none

    Encoding considerations: This media type is framed (see section 4.8
    in [freed]) and contains binary data.

    Restrictions on usage:
         This media type depends on RTP framing, and hence is only
         defined for transfer via RTP [3]. Transport within other framing
         protocols SHALL NOT be defined as this is a robustness mechanism
         for RTP.

    Security considerations: the same security considerations apply to
    these MIME registrations as to the payloads for them, as detailed in
    RFC xxxx.

    Interoperability considerations: none

    Published specification: RFC xxxx.

    Applications which use this media type: Audio and video streaming
    tools which seek to improve resiliency to loss by sending additional
    data with the media stream.

    Additional information: none

    Person & email address to contact for further information:
       Adam Li [email-masked]
       IETF Audio/Video Transport Working Group

    Intended usage: COMMON

    Author:
       Adam Li [email-masked]

    Change controller:
       IETF Audio/Video Transport Working Group delegated from the
       IESG.

Informative references:

[freed] Freed, N. and J. Klensin, "Media Type Specifications and
      Registration Procedures", draft-freed-media-type-reg-04, April
      2005.

[rfc3555] Casner, S. and P. Hoschka, "MIME Type Registration of RTP 
Payload Formats", RFC 3555, July 2003.

5. Section 13.2:

I think the usage of the ULP as redundant data is underspecified.

13.2. FEC as Redundant Encoding

    When the FEC stream is being sent as a secondary codec in the
    redundant encoding format, this must be signaled through SDP. To do
    this, the procedures defined in RFC 2198 [5] are used to signal the
    use of redundant encoding. The FEC payload type is indicated in the
    same fashion as any other secondary codec. The FEC MUST protect only
    the main codec.

    Because the FEC data is sent in the same packets as the protected
    payload, the ULP header of the FEC packets is not used. The FEC data
    is associated with the protected payload by being bundled in the
    same stream.

I would start with the last sentence of the first paragraph:
"The FEC MUST protect only the main codec." How is that possible? Should 
the FEC encoding engine create a virtual packet only containing the 
primary payload? The FEC mechanism defined protects complete packets, 
thus I think for simplicity one should protect the complete packet, 
including any FEC redundant payload parts of already sent packets.

Secondly, "Because the FEC data is sent in the same packets as the 
protected payload, the ULP header of the FEC packets is not used." How 
will it be possible to not have the ULP header?

6. Section 14. This section is missing an Offer/Answer consideration 
section. To my eye this would not be a long section however to show that 
it has been considered it is needed to be included.

If you like some help please ask me. However I don't have time to whip 
one together now.

7. The normative Reference list. I think it contains unnecessary 
references that are informative. Normative references are such 
references that are necessary to correctly implement this specification. 
  "Encode the binary data into a text string using BASE-64 [RFC3548]". 
Thus I think that reference 1, 2, 6, and 7 are not needed. In fact 
reference [7] is not used at all.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Andrea Lorenzo VITALI <[email-masked]>
Date: Wed, 27 Jul 2005 10:43:34 +0200

I have reviewed the draft and I have a couple of questions.

1) Have you considered the possibility to refer to non-consecutive RTP packets?

Currently, bits in the mask refer to consecutive RTP packets: starting from the
base sequence number SN: SN+0, SN+1, SN+2 ... SN+i, where 0<=i<24 in RFC2733 and
0<=i<16 or 0<=i<48 in ULP.

It has been proposed in the MPEG forum to refer to non-consecutive RTP packets
by specifying an offset L: SN+0*L, SN+1*L, ... SN+i*L, where 0<=i<24 as in RFC2733.

The document is available on the web at:
   http://www.pro-mpeg.org/publications/pdf/Vid-on-IP-CoP3-r2.pdf

2) What is the rational behind the costraint a) in par.7.5?

I copy it here for your convenience:
"     a. A media packet SHALL be protected only once at each
              protection level higher than level 0. A media packet MAY be
              protected more than once at level 0 by different packets,
              providing the protection lengths of level 0 of these packets
              are equal.
"

This poses constraints on raised bits in masks for level>0. But perhaps it would
be easier to let the user care and give an hint on the usefulness of the
constraint...

--

I have also a couple of remarks.

1) I was confused by reading in the introduction the following phrase:

"   Lower protection levels provide greater protection by using smaller
        group sizes (compared to higher protection levels) for generating
        the FEC packet.
"

"Lower protections levels" made me think about a low protection but then I read
"greater protection". The contradiction (low or great protection?) confused me.

Of course, this is a problem only for 1st time readers. However, it may be
useful to rephrase as follows:

"   High priority levels provide greater protection ...
        ... (compared to low priority levels ...
"

Then, it can be specified that levels are numbered from hi-pri to low-pri
starting from 0.

2) I appreciated the introduction and the reference to UXP.

It would be useful to include an extensive comparison, including:

   - XOR based FEC schemes as specified in RFC2733 and draft-ietf-avt-ULP-11

   - Reed-Solomon based schemes as specified in draft-ietf-avt-UXP-07, as 
proposed by Siemens/Nokia for 3GPP, as proposed for DVB-H (handheld) under the 
name "MPE_FEC".

   - LDPC (low density parity check codes) based schemes as proposed by INRIA

plus other schemes based on digital fountain codes.

Best regards,

       Andrea

-- 
      ______________________________________________________________

       Andrea VITALI                            [email-masked]

       tel (+39) 039 603 7244             mobile (+39) 347 93 08 433
       fax (+39) 039 603 6129

       STMicroelectronics
       Centro Direzionale COLLEONI - Palazzo "DIALETTICA"
       20041 Agrate Brianza (MI) ITALY
      ______________________________________________________________

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 28 Jul 2005 17:20:03 +0200

Hi

Please see below for my comments.

>    http://www.pro-mpeg.org/publications/pdf/Vid-on-IP-CoP3-r2.pdf

I have actually seen this proposal earlier and have quite mixed feelings 
about it. For a medium to high bandwidth application I can understand 
that 24 packets are to little. 48 makes it better but only goes half-way 
to the minimal 100 packets that the MPEG-PRO requires one to support.

As I see the solution is basically an interleaving scheme and could in 
it simplest form be implemented with a signalling attribute and a change 
to the derivation bit-mask to included packet algorithm.

However before changing the format I would like to know how big interest 
it really is of such a change. See also the next comment.

[snip]
> plus other schemes based on digital fountain codes.

On this topic I don't think the ULP draft is the right place to have a 
general overview of what possible solutions that exist. It is necessary 
to have a clear applicability section. Describing under which scenarios 
it makes sense to use this format.

When it comes to UXP their is some question if that work will progress 
or be replaced with a more generic framework based on RMT like building 
blocks (draft-watson-tsvwg-fec-sf-00). This will be discussed next week 
in Paris. So there is clearly interest of getting usage of some more 
advanced and better performing FEC codes.

Cheers

Magnus Westerlund