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

From: "Ingemar Johansson S" <[email-masked]>
Date: Thu, 2 Oct 2008 14:17:42 +0200

Hi

I believe that the idea to incorporate some dedicated signaling to
ensure fast synchronization between layers may have its merits.
Especially as RTCP-SR may after all be lost in transmission. This may
delay synchronization of all layers and thus full quality restoration by
a few seconds. The risk of RTCP loss depends greatly on the access
links. As discussed in the RTCP reduced-size draft RTCP-SR size may be a
problem in cases where the packetloss probability increases with packet
size (examples of this is highly optimized wireless links). Lack of
layers does not break things, one will however get a lower quality
experience. 

However, as the problem is general for layered codecs I am not sure
where the proposed solution fits best.
Also one could however argue against the above as loss of RTCP for the
higher layers may well indicate that the reception of the higher layer
is not reliable and therefore it does not make any difference if the
RTCP is lost or not..

/Ingemar
 
> Message: 4
> Date: Thu, 2 Oct 2008 13:02:57 +0300
> From: <[email-masked]>
> Subject: Re: [AVT] draft-lakaniemi-avt-rtp-evbr-03.txt submitted - on
> 	decoding order recovery
> To: <[email-masked]>
> Cc: [email-masked], [email-masked]
> Message-ID:
> 	
> <[email-masked]>
> Content-Type: text/plain;	charset="us-ascii"
> 
> >>> 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.
> >>>
> >>
> >> 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.
> >
> 
> After the statement was made by one voice
> (http://www.ietf.org/mail-archive/web/avt/current/msg10052.htm
> l), 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?
> 
> >> 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.
> >
> >You can configure the sender RTCP fraction to match the 
> required join  
> >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
> 
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: <[email-masked]>
Date: Thu, 2 Oct 2008 23:34:50 +0300

Hi Ingemar,

Thanks a lot for your opinion. However, do you have over 12 years of
experience of practice, standardization, and implementation in this
field? If no, your opinion cannot be counted. 

BR, YK 

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of ext Ingemar Johansson S
>Sent: 02 October, 2008 15:18
>To: [email-masked]
>Subject: Re: [AVT] draft-lakaniemi-avt-rtp-evbr-03.txt 
>submitted - ondecoding order recovery
>
>Hi
>

---

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

Sorry for the kidding - ignore my words below. 

I fully agree that possible loss of RTCP SRs is another shortage of
using this approach for decoder order recovery. This is true even the
RTP packets themselves may also be lost, because as long as not all
coded media data units are lost, the decoder may make use of the
received ones for improved playback quality.  

BR, YK

>From: Wang Ye-Kui (Nokia-NRC/Tampere) 
>Sent: 02 October, 2008 23:35
>To: 'ext Ingemar Johansson S'; [email-masked]
>Subject: RE: [AVT] draft-lakaniemi-avt-rtp-evbr-03.txt 
>Thanks a lot for your opinion. However, do you have over 12 
>years of experience of practice, standardization, and 
>implementation in this field? If no, your opinion cannot be counted. 
>
>BR, YK 
>

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Fri, 3 Oct 2008 09:19:48 +0200

Hi

I may be kicking in open doors but have you considered to use RTP header
extensions (RFC5285) for this purpose ?. 

Header ext. should make it possible to specify a generic mechanism for
synchronization of the layers. RTCP-SR will anyway be transmitted so
there will always be a safe fallback solution available in case.

One idea would be to put the reference TS (described in the -02 version
of the draft in the header extension.
The security considerations in RFC5285 must of course be taken care of
and here I belive that displaying the reference TS unencrypted is be a
security threat. However the security can only be breached if the
eavesdropper can listen to both the core layer and one extension layer.
Still it may be tricky to get acceptance for this.

To overcome this threat one could instead consider to put the NTP
(wallclock) time in the header extension field for all layers, it could
be just a part of the NTP or all 64 bits, I don't know. 
This would anyway mimic exactly how synchronization with RTCP-SR is
done. And one thing does not need to exclude the other , header ext. may
be used for fast synchronization while RTCP-SR is used to handle clock
drift.

/Ingemar

> From: [email-masked] [mailto:[email-masked]] 
> Sent: den 3 oktober 2008 07:17
> To: Ingemar Johansson S; [email-masked]
> I fully agree that possible loss of RTCP SRs is another 
> shortage of using this approach for decoder order recovery. 
> This is true even the RTP packets themselves may also be 
> lost, because as long as not all coded media data units are 
> lost, the decoder may make use of the received ones for 
> improved playback quality.  
> 
> BR, YK
>