Subject: [AVT] Comments on draft-ietf-avt-ulp-06.txt

From: Magnus Westerlund <[email-masked]>
Date: Tue, 05 Nov 2002 15:29:33 +0100

Hi,

I have rather many comments on this new version of the draft:

1. Usage of RTP header for ULP packets. Why is it not allowed to use 
header extensions. I don't see a reason to restrict this, it should be 
up to the application and be set in accordance with RTP.

2. Section 5.1 third paragraph. It specifies that the sequence number 
MUST be one higher than for the previous packet. If that is possible or 
not depends on the multiplexing scheme used and can't be defined here.

3. Section 5.3, fourth paragraph: "The SN base field in the FEC header 
MUST be set to the minimum sequence number of the packets ...". This 
definition must be improved, first I don't think the minimum sequence 
number is the correct one, is rather the earliest. Secondly this 
paragraph also needs to address sequence number wrapping.

4. Section 5.2, bullet "a". What is the reason that a the same bytes of 
a media packet may not be part of multiple ULP packets? I can see 
schemes that protect certain media packets multiple times to make the 
recovery more robust and not relying on that a single ULP packet shall 
not be lost. Or has I misunderstood what is meant here?
- Bullet "b": What is the reason for this? I can agree that it is 
recommended that you protect the lower levels better. But is there a 
protocol specification reason why I shouldn't be allowed to specify a 
Level 0 that protects no packet and then a Level 1 which protects some 
of these packets. The format should not protest except that I will need 
to add a null vector for the level 0.
- Bullet C: Must I really have the protection of lower layers in the 
same ULP packets as the one containing the higher levels?

5. Use of requirement levels. I think in many case you can be better 
with using the CAPITALIZED forms of MUST, SHALL, MAY, etc. One example 
is the bullet list in section 5.3.

6. The examples in section 8 are all having the old format. Also it 
would be clearer if also the level data is part of the example bit 
figures (can be abbreviated). Also in some cases it may better easier to 
read if the actual bits are replaced with decimal forms written within 
the field, for example the recovery length field. One is in most case 
interested in the fields placement and what value they shall contain, 
not seeing the actual bits.

7. The ULP multiplexing schemes. I think there is time to review the 
multiplexing schemes. To my understanding the ULP format could be 
multiplexed in the following ways:

PT-multiplexing: Simple send the ULP stream with the same SSRC as the 
original data and use the payload type to distinguish the ULP packets. 
This scheme is very simple but results has a couple of disadvantages: 
Impossible to determine if lost packets are original or FEC packets. 
Secondly some payload formats does not handle sequence number gaps 
produced by the ULP streams. Therefore this should not be used.

SSRC multiplexing: Use a different SSRC for the FEC packets. May be used 
for similar reasons that RTP retransmission can actually use the SSRC to 
multiplex. Some problem of binding the FEC stream to the original 
stream. Requires the use of RTCP and individual CNAMEs for each packet 
source in a session. Very qualified guesses are also possible to perform.

Session multiplexing: Use a different RTP session to carry the FEC 
packets. Has advantages for multicast where a different multicast 
address can be used which allows for each receiver to determine if he 
wants to use them or not. The same SSRC as the original stream's shall 
be used.

RFC2198-multiplexing: Allows for usage of a single stream. No problem of 
detecting which original stream it belongs to. No extra packets, less 
overhead. A packet loss of a packet costs both a original data block and 
the FEC data. Requires more implementation work and support from a 
receiver and sender.

I think one should discuss these techniques and which should be allowed 
to use. I think that Session multiplexing and SSRC multiplexing should 
be considered. The removal of RFC2198 would simplify implementation.

8. There exist another reason than mentioned why the ULP should obsolete 
RFC 2733. That is that it requires no change in the RTP packet 
processing which RFC2733 do.

9. One should also review the SDP signaling mechanisms. In the case of 
session multiplexing one might need to consider if the usage of FID to 
bind the FEC session to the original might be a better one. In that way 
one can have a m= line for each session needed and does not need to hide 
a session in the a=fmtp line. And that session can then have a proper PT 
declaration of  itself. Would remove the need for having FEC defined in 
the original session.

10. In the case of session multiplexing it should be clarified that one 
may not use a single FEC session for multiple original sessions. The 
reason is that SSRC collision may occur and avoidance does not work 
properly.

11. The RTSP control section are in error:
a: The description of aggregated control are in error. Even if 
aggregated control is used the FEC stream will need a individual control 
URL in the case of session multiplexing. However aggregated control 
should still be used in this case. Otherwise there will be  RTSP 
signaling overhead.
b. the a=fmtp attribute may be made clearer and easier to distinguish 
from the session defining one. But I would recommend that one change to 
using FID and declaring a individual m= line for the FEC session. In 
that way no special attribute are needed at all.
c. Allow SSRC multiplexing which allows for very simple RTSP control of 
sessions using FEC. No extra RTSP signaling will be required in this case.

12. Usage of ULP for different payload formats with different RTP 
timestamp rates. With this new proposal for XOR when the whole RTP 
header is part of the recovery data there is no need to have the RTP TS 
in the ULP packet bound to the original data. If bound to the original 
data it would be necessary to have one ULP PT for each RTP TS rate 
present in the session. Otherwise the PT is not possible to define as a 
PT is not allowed to use different rates. One should instead decide on a 
RTP TS that are good for detecting jitter and always stamp it with send 
time, e.g. 1000 Hz.

13. The MIME definition will have one required parameter rate unless we 
define it to a fixed value.

14. Has it been considered that it might be interesting to combine a ULP 
packet that protects several sources? I guess it is to farfetched and 
has severe problems with overhead as the SSRC would be required in the 
header.

Best Regards

Magnus Westerlund 

Multimedia Technologies, Ericsson Research ERA/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: "Adam Li" <[email-masked]>
Date: Tue, 5 Nov 2002 10:50:46 -0800

Dear Magnus,

Thank you very much for the comments and the suggestions. I will work on
these and fix or clarify the draft in the next revision.

Last weekend, we have submitted one more revision before the deadline of
-0x versions (still not announced by the ID manager yet at this time).
That was the version -07 and did not address your comment here. These
comments will be addressed in version -08 later.

Thanks a lot.

Adam

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Magnus
> Westerlund
> Sent: Tuesday, November 05, 2002 6:30 AM
> To: IETF AVT WG
> Subject: [AVT] Comments on draft-ietf-avt-ulp-06.txt
> 
> Hi,
>