Subject: Re: [AVT] draft-lakaniemi-avt-rtp-evbr-03.txt submitted

From: Colin Perkins <[email-masked]>
Date: Wed, 1 Oct 2008 16:31:05 +0100

On 28 Sep 2008, at 13:36, <[email-masked]> wrote:
> draft-lakaniemi-avt-rtp-evbr-03.txt
> (http://www.ietf.org/internet-drafts/draft-lakaniemi-avt-rtp- 
> evbr-03.txt
> ) has been submitted.
>
> I have addressed the comments Colin sent on 1 September that should be
> addressed before accepting the draft as a WG item. Some other changes
> have also been made. A a list of open issues has been added in  
> section 9
> and changes compared to -02 are summarized in section 10.

As I said before, we really don't want to have different ways of  
doing cross-layer synchronisation for different payload formats; that  
would complicate implementations for no good reason. Accordingly, I  
think this draft should say that implementations "MUST use the RTCP  
SR information to synchronise streams". The current wording, in  
section 3.6, saying "SHOULD" is insufficient. It's also not clear  
what the Author's Note in section 3.6 means when it states that the  
standard mechanism imposes higher end-to-end delay or higher  
bandwidth for RTCP data, and might not work for multicast.

The draft also appears to misunderstand the definition of an RTP  
session in RFC 3550, talking about dividing the data over multiple  
RTP sessions, when it appears that the data is divided across  
multiple streams of RTP data in a single RTP session (bullet 2 of  
section 2.3, and throughout). This makes, for example, section 3.6  
impossible to implement (since SSRC values are not guaranteed to be  
unique across different RTP sessions). The concept of splitting the  
data up across multiple flows is good, but the explanation needs to  
be brought into line with RFC 3550.

[Earlier versions of the SVC draft had similar problems; I haven't  
read the latest version to check if they've been resolved]

The use of partials CRCs is unusual, and poorly explained. Since RTP  
is almost always run on lower layer protocols that have their own  
checksums, it's not clear what benefit there is to these CRCs.

-- 
Colin Perkins
http://csperkins.org/

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

---

From: "Alex Eleftheriadis" <[email-masked]>
Date: Wed, 1 Oct 2008 19:18:15 +0300

On Oct 1, 2008, at 6:33 PM, "Colin Perkins" <[email-masked]> wrote:

>> (http://www.ietf.org/internet-drafts/draft-lakaniemi-avt-rtp-evbr-03.txt
>> ) has been submitted.
>>
> doing cross-layer synchronisation for different payload formats;  
> that would complicate implementations for no good reason.  
> Accordingly, I think this draft should say that implementations  
> "MUST use the RTCP SR information to synchronise streams". The  
> current wording, in section 3.6, saying "SHOULD" is insufficient.  
> It's also not clear what the Author's Note in section 3.6 means when  
> it states that the standard mechanism imposes higher end-to-end  
> delay or higher bandwidth for RTCP data, and might not work for  
> multicast.
>

The SVC draft uses the correct definition.

--Alex

---

From: <[email-masked]>
Date: Thu, 2 Oct 2008 00:55:33 +0300

>bandwidth for RTCP data, and might not work for multicast.

My understanding is that, during the recent *a lot* discussion on this
issue, it has not been clearly concluded that the RTCP SR based method
*MUST* be used for any functionality based on time sync. I think
Jonathan and Thomas are checking whether other approaches may also be
used in a coming draft. Therefore, I think having a note mentioning this
is not unreasonable. We should certainly change "SHOULD" to "MUST" if a
clearer picture is available.  

For multicast, you need to enable tune-in and channel switching,
therefore you must send RTCP SRs frequently enough. If the tune-in or
channel switching delay is relatively low, then the number of sent RTCP
SRs would be relatively high, which certainly means higher bandwidth for
RTCP data. On the other hand, if bandwidth used for RTCP data is low,
then tune-in or channel switching delay is high. For multicast cases
with larger numbers of receivers, the bandwidth allocated for RTCP may
be not high enough to enable required tune-in or channel switching
delay. 

>be brought into line with RFC 3550.

Bullet 2 of section 2.3 says: "The encoded data is divided over multiple
RTP sessions, each session carrying a subset of layers. This is also
referred to as Multi-Session Transmission (MST)."

How could you get the conclusion "that the data is divided across
multiple streams of RTP data in a single RTP session"? Also, where else
in the document this aspect is not clear?

>The use of partials CRCs is unusual, 

The use of partial CRCs is also included in RFC 4867 (RTP Payload Format
and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive
Multi-Rate Wideband (AMR-WB) Audio Codecs). Note also that EVBR has the
AMR-WB compatible mode. 

> and poorly explained. 

Could you please point out what aspects need to be improved to make the
explanation not poor (besides the benefit as discussed below)?

> Since RTP  

The benefit can be found in section 3.6 of RFC 4867. If it is not
decided to remove this support, I will add the reasoning to the draft.

BR, YK

---

From: Colin Perkins <[email-masked]>
Date: Thu, 2 Oct 2008 09:30:52 +0100

On 1 Oct 2008, at 22:55, <[email-masked]> wrote:
> My understanding is that, during the recent *a lot* discussion on  
> this issue, it has not been clearly concluded that the RTCP SR  
> based method *MUST* be used for any functionality based on time  
> sync. I think Jonathan and Thomas are checking whether other  
> approaches may also be used in a coming draft. Therefore, I think  
> having a note mentioning this is not unreasonable. We should  
> certainly change "SHOULD" to "MUST" if a clearer picture is available.

I disagree: the RTCP SR based mechanism is the only defined mechanism  
for synchronisation of RTP streams, and must be used.

> channel switching delay is relatively low, then the number of sent  
> RTCP SRs would be relatively high, which certainly means higher  
> bandwidth for RTCP data. On the other hand, if bandwidth used for  
> RTCP data is low, then tune-in or channel switching delay is high.  
> For multicast cases with larger numbers of receivers, the bandwidth  
> allocated for RTCP may be not high enough to enable required tune- 
> in or channel switching delay.

You can configure the sender RTCP fraction to match the required join  
latency. There are also proposals to use unicast RTCP SRs for faster  
joins.

> Bullet 2 of section 2.3 says: "The encoded data is divided over  
> multiple RTP sessions, each session carrying a subset of layers.  
> This is also referred to as Multi-Session Transmission (MST)."
>
> multiple streams of RTP data in a single RTP session"?

You appear misunderstand the definition of an RTP session, and assume  
that each UDP flow is a separate RTP session. That is not the case.  
For example, if you send the base layer as a stream of RTP data on  
UDP port 5004, and the enhancement layer as a separate stream of RTP  
data on UDP port 5006, that comprise one RTP session, not two.

> Also, where else in the document this aspect is not clear?

Every time you mention RTP sessions.

> The use of partial CRCs is also included in RFC 4867 (RTP Payload  
> Format and File Storage Format for the Adaptive Multi-Rate (AMR)  
> and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs). Note also  
> that EVBR has the AMR-WB compatible mode.

Sure, but this only works in the case of a transport layer with  
partial   checksums, and is used for intra-packet reliability. Your  
draft looks to use the checksums across packets, which makes no sense.

Also, it's not clear if the partial checksum features of AMR are  
useful in practice. They were controversial, and it's not clear they  
were a good idea.

-- 
Colin Perkins
http://csperkins.org/

---

From: <[email-masked]>
Date: Thu, 2 Oct 2008 11:38:33 +0300

>that each UDP flow is a separate RTP session. That is not the case.  

Could you please point out which part of the text indicates this
understanding?

>data on UDP port 5006, that comprise one RTP session, not two.

I understand this, but I don't think the draft has anything like this.

>Every time you mention RTP sessions.

Please be specific - even just one place!

BR, YK

>-----Original Message-----
>From: ext Colin Perkins [mailto:[email-masked]] 
>Sent: 02 October, 2008 11:31
>To: Wang Ye-Kui (Nokia-NRC/Tampere)
>Cc: [email-masked]; [email-masked]
>Subject: Re: [AVT] draft-lakaniemi-avt-rtp-evbr-03.txt submitted
>

---

From: Colin Perkins <[email-masked]>
Date: Thu, 2 Oct 2008 10:44:22 +0100

On 2 Oct 2008, at 09:38, <[email-masked]>  wrote:
>>>> session in RFC 3550, talking about dividing the data over  
>>>> multiple RTP sessions, when it appears that the data is divided  
>>>> across multiple streams of RTP data in a single RTP session  
>>>> (bullet 2 of section 2.3, and throughout). This makes, for  
>>>> example, section 3.6 impossible to implement (since SSRC values  
>>>> are not guaranteed to be unique across different RTP sessions).  
>>>> The concept of splitting the data up across multiple flows is  
>>>> good, but the explanation needs to be brought into line with RFC  
>>>> 3550.
>>>
>> You appear misunderstand the definition of an RTP session, and  
>> assume that each UDP flow is a separate RTP session. That is not  
>> the case.
>

Bullet 2 of section 2.3, as I mentioned in my previous email.

>> UDP port 5004, and the enhancement layer as a separate stream of  
>> RTP data on UDP port 5006, that comprise one RTP session, not two.
>

Bullet 2 of section 2.3.

> Please be specific - even just one place!

As I mentioned in my original message, section 3.6.

-- 
Colin Perkins
http://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Thu, 2 Oct 2008 10:52:54 +0100

On 2 Oct 2008, at 10:44, Colin Perkins wrote:
>>>>> The draft also appears to misunderstand the definition of an  
>>>>> RTP session in RFC 3550, talking about dividing the data over  
>>>>> good, but the explanation needs to be brought into line with  
>>>>> RFC 3550.
>>>>
>>> For example, if you send the base layer as a stream of RTP data  
>>> on UDP port 5004, and the enhancement layer as a separate stream  
>>> of RTP data on UDP port 5006, that comprise one RTP session, not  
>>> two.
>>

Actually, that one is okay. Section 3.7 has odd rules for RTP payload  
type usage across RTP sessions though.

This is mostly just a terminology issue, however. The other points in  
my message were the more critical ones, and I suggest we don't fixate  
on the editorial issues to the exclusion of the technical.

-- 
Colin Perkins
http://csperkins.org/

---

From: <[email-masked]>
Date: Thu, 2 Oct 2008 13:02:57 +0300

>for synchronisation of RTP streams, and must be used.

After the statement was made by one voice
(http://www.ietf.org/mail-archive/web/avt/current/msg10052.html), there
have been three voices saying something different
(http://www.ietf.org/mail-archive/web/avt/current/msg10054.html,
http://www.ietf.org/mail-archive/web/avt/current/msg10057.html,
http://www.ietf.org/mail-archive/web/avt/current/msg10067.html),
excluding one additional from myself
(http://www.ietf.org/mail-archive/web/avt/current/msg10060.html). So
from this fact we can draw a conclusion that the statement from only one
voice against others is a rough consensus?

>latency.

Two points: 
- The total RTCP bandwidth for both senders and receivers is limited.
- There may be a lot of senders, and when the number of senders is more
than one quarter of the membership, the sender RCTP bandwidth is shared
between the senders. 

> There are also proposals to use unicast RTCP SRs for faster  
>joins. 

There are a lot of applications not implementing those PROPOSALS. 

BR, YK

---

From: <[email-masked]>
Date: Thu, 2 Oct 2008 13:09:27 +0300

>Sent: 02 October, 2008 12:53
>To: Colin Perkins
>Cc: Wang Ye-Kui (Nokia-NRC/Tampere); [email-masked]; 
>[email-masked]

Agreed. Requiring use of different PT values for different RTP sessions
is not needed. I will align this with SVC. Thanks!

>on the editorial issues to the exclusion of the technical.

Agreed. 

BR, YK

---

From: <[email-masked]>
Date: Thu, 2 Oct 2008 13:19:53 +0300

>draft looks to use the checksums across packets, which makes no sense.

No, in the draft a checksum is used across transport blocks within a
single packet, but not across packets. 

>useful in practice. They were controversial, and it's not clear they  

OK. I have no comment on this. If there is a consensus on this, then CRC
support may be removed from the draft. Therefore, some opinions from
others would be helpful. 

BR, YK

---

From: Colin Perkins <[email-masked]>
Date: Thu, 2 Oct 2008 11:26:18 +0100

On 2 Oct 2008, at 11:02, <[email-masked]> wrote:
> from this fact we can draw a conclusion that the statement from  
> only one voice against others is a rough consensus?

You seem to be ignoring over 12 years of existing practise,  
standards, and implementations.

> - There may be a lot of senders, and when the number of senders is  
> more than one quarter of the membership, the sender RCTP bandwidth  
> is shared between the senders.

Yes, that's the nature of RTP. If you want faster synchronisation,  
then you need to increase the RTCP bandwidth fraction.

-- 
Colin Perkins
http://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Thu, 2 Oct 2008 21:30:02 +0200

> single packet, but not across packets.

In which case, section 3.1.1 needs clarification, since "the payload  
checksum is valid for any integer number of contiguous transport  
blocks starting from the beginning of the primary transport block"  
can be read as implying this is valid across packets, not just within  
a packet.

Also, if you want to use partial checksums, the draft needs to refer  
to the UDP-lite and/or DCCP specifications, and include a discussion  
about partial checksums at the transport layer, to explain when the  
CRC is useful. It's not obvious how it can be used, from the current  
draft.

-- 
Colin Perkins
http://csperkins.org/

---

From: <[email-masked]>
Date: Fri, 3 Oct 2008 08:18:10 +0300

Fully agree all the points below. Thanks! Will update these in the next
version.

BR, YK 

>Sent: 02 October, 2008 22:30
>Subject: Re: [AVT] draft-lakaniemi-avt-rtp-evbr-03.txt 
>submitted - on CRC
>

---

From: Randell Jesup <[email-masked]>
Date: Fri, 03 Oct 2008 01:23:37 -0400

<[email-masked]> writes:
>>> used in a coming draft. Therefore, I think having a note mentioning
>>> this is not unreasonable. We should certainly change "SHOULD" to "MUST"
>>> if a clearer picture is available.
>>

Just because people didn't 'vote' on it by posting to the list doesn't mean
that they agree (or disagree); and of the 3 responses other than Colin's
you mention, at least 1 and I'd say 2 don't really disagree with Colin.

I've said things similar to Colin on a number of occasions in the past
(before the most-current incarnation of the discussion).  The last time
this came up (a few months ago?  6 months?), after my listing the serious
problems with both linked timestamps (your suggestion at the time) and
startup-time sync recovery with the standard SR-based mechanism, it was
suggested I write a draft on how to minimize startup sync delay.  I'm
afraid I haven't done so (partly due to lack of time and that I'm a new
father - closely related issues...).

I do agree that multiple-stream/scalable codecs have some additional needs
or at least desires for fast cross-stream synchronization, while lip-sync
can often run un-synced for a while with (hopefully) minor impact.  I
proposed some alternatives in that earlier conversation.

If there *is* to be a new mechanism (or new way to use the existing
mechanism), I STRONGLY suggest it be a separate draft that can be used with
more than one codec.  That draft could extend or replace any "MUST" in
this one.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)

---

From: <[email-masked]>
Date: Fri, 3 Oct 2008 09:04:03 +0300

>From: ext Randell Jesup [mailto:[email-masked]] 
>Sent: 03 October, 2008 08:24
>Cc: [email-masked]; [email-masked]; [email-masked]
>submitted - on decoding order recovery
>

I did not say that they were really disagreeing with Colin. I said they
were saying something different. I believe you are saying something
different too - in you opinion a new mechanism may be allowed, this
seems indicating that you would be fine with the word "SHOULD" in the
following in the draft, at least temporarily:

   The receiver SHOULD use the traditional RTCP based mechanism to 
   synchronize streams by using the RTP and NTP timestamps of the RTCP 
   Sender Reports (SR) it receives.   
             Author's note: The above approach for cross-session 
             synchronization is not possible until the first RTCP SRs 
             are received in all sessions. This implies that decoding 
             only a subset of layers may be possible until RTCP SRs in 
             all sessions have been received. This may imposes higher 
             end-to-end delay or higher bandwidth for RTCP data, and 
             the approach may not work perfectly for some multicast 
             topologies. There is a study ongoing by some AVT members. 
             Once there is an acceptable solution the draft documenting 
             that solution may be referenced herein.  

BR, YK

---

From: "Roni Even" <[email-masked]>
Date: Fri, 3 Oct 2008 19:31:05 +0300

YK,
I think that the major open issue that need to be resolved is this one.
I looked at the email thread and my view is that no one contradicts Colin's
point and are not claiming that using RTCP SR does not work. They point at
implementation issues but not at the general model.
I would recommend to use Colin's language that RTCP SR MUST be used. 

Having a note with a forward looking statement may be confusing to a reader
who did not follow the discussion. 
If there will be another way to synchronize in the future this draft as well
as other layered codecs that will choose to use it can update the payload
specification.
I see no problem with future interoperability since the RTCP SR will need to
be sent anyhow and a new option will require the receiver to signal that it
supports it and then it is up to the receiver to use which method he want,
still he will need to support RTCP SR for backward compatibility.

Roni 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Thursday, October 02, 2008 1:03 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [AVT] draft-lakaniemi-avt-rtp-evbr-03.txt submitted - on
decoding order recovery

Two points: 

BR, YK

---

From: <[email-masked]>
Date: Fri, 3 Oct 2008 19:39:26 +0300

Roni,

Thanks for your time and clarification. I will use "MUST" and remove the
note in the next version. 

BR, YK 

>From: ext Roni Even [mailto:[email-masked]] 
>Sent: 03 October, 2008 19:31
>To: Wang Ye-Kui (Nokia-NRC/Tampere); [email-masked]
>Subject: RE: [AVT] draft-lakaniemi-avt-rtp-evbr-03.txt

---

From: "Roni Even" <[email-masked]>
Date: Fri, 3 Oct 2008 19:31:05 +0300

YK,

Roni 

-----Original Message-----

Two points: 

BR, YK

---

From: "Roni Even" <[email-masked]>
Date: Fri, 3 Oct 2008 21:38:02 +0300

Randell,
I hope that you will find the time to write such draft but since there were
others who had concerns maybe someone will try to at least try to write a
draft with the problem statement that will include also the scenarios where
there are concerns about using RTCP SR for time synchronization.
I noticed from the email thread that people are listing different issues
when pointing out constrains of RTCP SR. (like clock resolution, congestion,
setup time )
Thanks
Roni Even

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Randell Jesup
Sent: Friday, October 03, 2008 8:24 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [AVT] draft-lakaniemi-avt-rtp-evbr-03.txt submitted - on
decoding order recovery

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS
team
[email-masked]
"The fetters imposed on liberty at home have ever been forged out of the
weapons
provided for defence against real, pretended, or imaginary dangers from
abroad."
		- James Madison, 4th US president (1751-1836)

---

From: Thomas Schierl <[email-masked]>
Date: Fri, 03 Oct 2008 21:25:28 +0200

Our draft is almost complete and we will submit it soon.

Thomas

Roni Even wrote:

Randell,

-----Original Message-----

--
Thomas Schierl
--------------
Fraunhofer HHI

----

Visit us at

GITEX 2008 / Dubai, Int. Convention and Exhibition Centre / 19 - 23 October 2008 / Hall 2, Booth J2-6

http://www.gitex.com/Default_en_gb.aspx

---

From: Stefan Döhla <[email-masked]>
Date: Mon, 06 Oct 2008 10:21:06 +0200

Roni,

in the draft for MPEG Surround audio we also used the "MUST", since we 
(1) now only have RTCP as the valid mechanism and (2) any additional 
mechanism will only be an extra additive that must not break the RTCP 
mechanism.

So I fully concur with your text below.

Cheers
- Stefan

Roni Even wrote:
>>>> doing cross-layer synchronisation for different payload 
>>>>         
>> formats; that
>>     
>>> certainly change "SHOULD" to "MUST" if a clearer picture is 
>>>       
>> available.
>>

-- 
Dipl.-Ing. Stefan Döhla     | Email: [email-masked]
Multimedia Transport        | Phone: +49 (0)9131 776 6042 (!NEW!)
Audio Department            | Fax:   +49 (0)9131 776 6099 (!NEW!)
Fraunhofer IIS              |
Am Wolfmantel 33            |
91058 Erlangen, Germany     | Web:   http://www.iis.fraunhofer.de/amm