Subject: [AVT] Comments on draft-ietf-avt-rtp-selret-05

From: Magnus Westerlund <[email-masked]>
Date: Fri, 05 Jul 2002 14:20:08 +0200

Hi,

In this mail I have my comments on the selective retransmission draft. I 
would like to remind people about my mail about merging this draft with 
the other retransmission draft. I would also strongly encourage to also 
look at my comments regarding the other retransmission draft.

Section 4. Fifth paragraph:
I haven't seen any comments about the importance of RTCP SR from the 
sender to detect loss of the last packet before a transmission pause 
interruption. The last packet(s) can't be detected through detection of 
sequence number gaps as no more packets arrive. These can be detected by 
the RTCP SR packet count. These lost packet may not be that important at 
the end of a media stream, but if the stream only temporary has been 
halted and will later be resumed they may be significant and should be 
retransmitted.

I would also like to repeat my opinion that the payload format and SDP 
signaling should be aligned between the two proposals. These would make 
implementations of both solutions much easier.

Section 5.2:
I am lacking a description of what to do with any CRSC list or RTP 
header extensions in the original packet. Also the issue of padding 
should be addressed. I also find the notion of Media Payload Type 
specific header somewhat strange. It should be better defined what you 
mean with it.

Section 5.3
When looking at figure 3 it asked my self the question if it is allowed 
to strip away old SEL headers? Is it allowed and what effect would that 
have.

Section 6. (Delta) RTP Sequence Number
This definition ends very strange. Also when X=1 it is unclear in the 
text if one should use the Delta parts 8 bits as the high bits of the 
sequence number or add 16 new bits.

Section 10.1:
The rtx-time-val is a problematic value. In a On demand streaming case 
this can't be set by the server. The time from the server sends the 
packet until it is to late is rather unknown by the server. This time 
consist of two different times, the network delay between server and 
client, and the clients buffering time. The network delay can be 
estimated but may vary during the session. The buffering time at the 
client depends on buffer size and model. Also this may change. So I 
don't believe in the server specifying a value. I would rather argue 
that the client only request retransmission of things that has a 
potential of reaching the client in time. The server may effect what is 
retransmitted due to congestion considerations and prioritization of 
different packets.

Otherwise the SDP signaling has a couple of problems.
- How is the RTP TS rate set for the RTX traffic in cases when the 
original media packets can have different rates. As example a session 
with AAC using 90000 in TS rate and AMR-WB using 16000, what happens 
with the RTX rate.
- If the two drafts remain you should decide who has the right to use 
the MIME subtype name of RTX.
- A more clear specification should exist on how values are assigned to 
SDP, see section 8.3 of RFC 3267 as example.
- Should any more parameters be specified for the fmtp line to tell how 
the SEL and RTX is used?

Section 11.4
In the example you have the following media line:
m = video 8000/3 RTP/AVPF 98 99
Shouldn't that be /6? Or are the RTP ports automatically assumed to be 
the next even ports due to RTP/AVPF?

The draft is lacking an IANA section. You need to register MIME types 
for both formats, potentially for all the four media types that we 
currently transport over RTP, application, audio, video, and text.

Security considerations.
Shouldn't this section cover something about what can happen if I modify 
some fields in the defined payload formats or add a payload. 

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: Colin Perkins <[email-masked]>
Date: Mon, 08 Jul 2002 12:12:28 -0400

Hi,

A quick clarification, I agree with your other comments.

--> Magnus Westerlund writes:
...
>the next even ports due to RTP/AVPF?

The ports depend on the transport protocol, and if RTP is used the /3
represents the number of port pairs (see discussion of m= in SDP).

>currently transport over RTP, application, audio, video, and text.

Yes.

>some fields in the defined payload formats or add a payload. 

Yes, to both.

Colin

---

From: José Rey <[email-masked]>
Date: Wed, 10 Jul 2002 14:57:56 +0200

Hi Magnus,

thanks a lot for your comments, please see mine inline...

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]]Im Auftrag
> von Magnus
> Westerlund
> Gesendet: Freitag, 5. Juli 2002 14:20
> An: IETF AVT WG
> Betreff: [AVT] Comments on draft-ietf-avt-rtp-selret-05
>
>
> Hi,
>

This is a good point! I think this is something to which the implementer
should pay attention. I could add an appropriate sentence addressing this
issue in section 5.1 General Usage Rules.

> implementations of both solutions much easier.

Right.

> specific header somewhat strange. It should be better defined

The section says that the RTP header is stripped off. Since the CSRC list,
if
present, is part of the RTP header it should also be stripped off.

About the header extensions, bullet 1 in 5.2 states that "It is important to
note
that only the RTP header is stripped off, payload format specific headers
are kept as they are".
Header extensions are payload format specific headers,
therefore they should be kept as part of the payload for the current
retransmission. If the wording is not clear enough I could change
"payload-specific headers" with "header extensions".

As for the padding, something like "When performing encryption and after
adding a payload header, padding should be performed if needed to comply
with the required byte alignment of the used encryption method, e.g. when
using Secure RTP [xxx] to align to the 4-byte boundary". Comments are
welcome.

About the media payload type: it means the specific header of the coded
media carried in the RTP packet, e.g. MPEG. The examples (following in the
same section) try to graphically explain where the term comes from. I will
explicitly mention as I see it still results difficult to understand.

> to strip away old SEL headers? Is it allowed and what effect

Our original assumption was that it should be easier for the server just
to strip off the RTP header as a whole and don't parse the other headers.
This should avoid having to look into the different payload headers and
decide what to strip off for each packet.

On the other hand, if  b) does not represent a processing overhead for the
particular implementer, it could be changed to make the keeping of old SEL
headers optional. In that case there would be only 1 SEL header per packet,
the last one.

Note though, that the cumulated RTX headers would still have to be sent in
order to fill in the unidentified gaps in the SN space. The receiver would
otherwise think that it is still missing packets.

> sequence number or add 16 new bits.
Thanks, I will fix this.

> retransmitted due to congestion considerations and prioritization of

I agree that the sample description is uncomplete.

In the scenarios we had in mind the client buffer size could be a
limitation. But we also considered the case in which the server buffer space
is the limitation. In general, you don't know if the client uses a laptop
with much harddisk space or a mobile terminal with less space. Both cases
are:

1) the server buffer space is limited: upon a client description request,
the server describes (e.g. by means of a DESCRIBE RTSP reponse) the
available retransmission buffer space (e.g. in seconds) at the server for
this particular session and the particular encoded media rate (I noticed
after your comments an additional "b = " line indicating the bandwidth of
the media is also missing to translate seconds into bytes). Upon reception
of such a description the client can accept the proposed buffer by the
server or reduce it, because he has less. The client would signal a
reduction of the server buffer because it would make no sense to save more
at the server than the client could request.

2) only the client buffer size is the limitation: in this case the buffer
would be signaled, as you say, by the client's buffering algorithm.

We considered the two scenarios, but it may well be that 1) is not
realistic. In this case, one wouldn't need rtx-time-val. Should we keep 1)?

> with AAC using 90000 in TS rate and AMR-WB using 16000, what happens

I didn't think of it. Do you have a suggestion how to do that?

> SDP, see section 8.3 of RFC 3267 as example.

Thanks for the pointer! I will fix that.

> - Should any more parameters be specified for the fmtp line
> to tell how the SEL and RTX is used?
>

For the draft "as is" now, we do not see any further parameters need. Do you
have any usage combination in mind which is not covered? am I missing
something?

> the next even ports due to RTP/AVPF?

Although Colin was quicker than me, I keep the answer here....

Yes, even ports are suppossed due to RTP.  taken from SDP:
"

     For applications where hierarchically encoded streams are being
     sent to a unicast address, it may be necessary to specify multiple
     transport ports.  This is done using a similar notation to that
     used for IP multicast addresses in the "c=" field:

          m=<media> <port>/<number of ports> <transport> <fmt list>

     In such a case, the ports used depend on the transport protocol.
     For RTP, only the even ports are used for data and the
     corresponding one-higher odd port is used for RTCP.  For example:

                         m=video 49170/2 RTP/AVP 31

     would specify that ports 49170 and 49171 form one RTP/RTCP pair and
     49172 and 49173 form the second RTP/RTCP pair."

> currently transport over RTP, application, audio, video, and text.
Yepp! Working on it....

> some fields in the defined payload formats or add a payload.
Of course padding should be appended after adding the SEL/RTX header(s) or a
payload to be 4-byte aligned. The encrypting of the RTP header extensions
should remain optional, as in the SRTP draft.

thanks again for your comments,

José

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 10 Jul 2002 16:52:35 +0200

Hi José,

See my replies inline.

>explicitly mention as I see it still results difficult to understand.

Actually the header extension is for payload format independent stuff, 
see 5.3.1 in RTP spec. Therefore it is a question if they should also be 
stripped. I would also strongly recommend people to use the terms that 
are already defined. If it was header extensions that was meant it 
should say header extensions.

SRTP does not need to be padded to 4 byte alignment. I would say that 
padding should be stripped before retransmission and then reapplied if 
necessary when the new packet is sent.

>otherwise think that it is still missing packets.
One advantage of stripping the old SEL header is that it saves bits. I 
don't see an disadvantage as the old headers are outdated and does not 
bring the receiving part any more information.

>realistic. In this case, one wouldn't need rtx-time-val. Should we keep 1)?
I could see that the parameter is is redefined to mean the minimum time 
the server/counter part will keep the packets in its buffers to be able 
to retransmit them. Such a parameter would be useful. One should also 
take care to give good recommendations on how long time the a server 
should keep or calculate good values. It will of course be application 
specific.

>I didn't think of it. Do you have a suggestion how to do that?
Not for the moment. I will let you know if I get an idea.

>have any usage combination in mind which is not covered? am I missing
I guess not.

>should remain optional, as in the SRTP draft.
What I meant was that the section should describe what can happen if I 
as a bad guy has the possibility to modify the SEL or RTX header or add 
extra ones. It might not be the easiest attack to do but if it has 
severe effects it might be worth it. 

Regards

Magnus Westerlund