Subject: Re: [AVT] New draft on rapid synchronization

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Fri, 20 Feb 2009 13:31:46 -0500

This note is in response to "Extensions to RTCP for Rapid
Synchronization draft-peilin-avt-rtp-burst-00.txt" from P. Yang and B
Lei. It is encouraging to see that the authors agree with the broad
methodology of the previous drafts around rapid acceleration of
synchronization RTP multicast sessions. Hopefully we are converging on a
common solution. There are some areas of this draft that I need some
clarification on , though.
 
Steps 1-3 appear to be functionally equivalent to the flows previously
described. As previously stated, this is a promising step.
 
In step 4, the receiver does an analysis of the incoming unicast burst
to determine the optimum acceleration rate. The underlying assumption
appears to be that packet loss is congestion driven. How does this
method behave if the loss is due to other sources, such as noise on the
last mile plant? Can the receiver differentiate between congestive loss
and non-congestive loss? I have seen some analysis that claims to be
able to differentiate between the two types of loss, but it is not clear
(to me) if this is assumed in this case.
 
Clearly, if the link is driven into saturation, loss will result. I
would also like to understand the mechanism by which the RR and RS
recover from deterministic (congestion-based) loss. I have personally
been using a mental model in which the loss rate during acceleration is
approximately the same as any other time on the network, and many
(most?) acceleration bursts will complete without the need for
additional repair packets. To be honest, I have not given much thought
to a model in which there may be deterministic loss on every channel
change. What impact does this have on the scalability of the system?
 
I also realize that I have been assuming a model in which the
acceleration flows can't cause congestive loss in a video flow - either
through admission control or by using different QOS markings for the two
flows. More on this in my questions about step 10.
 
In steps 6-7, there appears to be a deterministic round-trip-time delay
between the sender catching up to realtime and the cessation of the
unicast flow. In the previous models, the design goal is have the
unicast flow cease at approximately the same time as it catches up to
the multicast flow at the receiver. I am trying to understand the
relative merits of having a handshake (with its resultant RTT-scale
delay) and pre-signaling the transition.  I am particularly interested
in the behavior when one or more of the packets in the handshake are
dropped.
 
In step 10, the receiver assumes that the steady state found in previous
multicast synchronization attempts is a good starting point. I am also
interested in this stage of the proposal. I have been assuming that the
channel is fairly dynamic, with other devices contending for the
bandwidth resources. In some cases, the video is from the same QOS pool
as acceleration bandwidth and is thus subject to admission control. In
this case, the maximum rate can be determined directly. In other cases,
the video is in a different (hopefully higher) QOS pool than the
acceleration data. In this case, the acceleration burst is contending
with other (presumably rate-adaptive) flows. When contending with other
rate adaptive flows, it is not clear that the available bandwidth of the
bottleneck link is the same as the last instantiation of the protocol.
For most of the modeling I have been doing, I have been assuming that
rate - adaptive  flows do not compete with multicast video flows due to
the detrimental effects of of congestive packet loss on video. Perhaps
this assumption is core to my questions earlier in this note.

I look forward to exploring these issues further.
 
Bill VerSteeg

________________________________

From: Roni Even [mailto:[email-masked]] 
Sent: Wednesday, January 28, 2009 2:53 AM
To: Bill Ver Steeg (versteb); 'Orit Levin'; 'VAN CAENEGEM Tom'; Dave
Oran (oran); Ali C. Begen (abegen)
Cc: 'Tom Taylor'; 'IETF AVT WG'
Subject: New draft on rapid synchronization

Hi guys,

Please note that
http://tools.ietf.org/id/draft-peilin-avt-rtp-burst-00.txt is discussing
the same topic.

I suggest you review it and take this work into account.

Thanks

Roni Even

---

From: Peilin YANG <[email-masked]>
Date: Mon, 23 Feb 2009 20:02:10 +0800

Dear Bill,

Thank you very much for your review. Please see my inline response. 

I will be happy to explore these issues further with you. And I also hope I can meet and discuss with you in SF meeting if the Consulate General in Shanghai can grant an American visa to me.

Kindly regards,

Peilin

******************************************************************************************
 This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email
 immediately and delete it!
 *****************************************************************************************

----- 原邮件 -----
发件人: "Bill Ver Steeg (versteb)" <[email-masked]>
日期: 星期六, 二月 21日, 2009 上午2:32
主题: Re: [AVT] New draft on rapid synchronization
收件人: Roni Even <[email-masked]>, Orit Levin <[email-masked]>, VAN CAENEGEM Tom <[email-masked]>, "Dave Oran (oran)" <[email-masked]>, "Ali C. Begen (abegen)" <[email-masked]>
抄送: Tom Taylor <[email-masked]>, IETF AVT WG <[email-masked]>

> last mile plant? Can the receiver differentiate between congestive 
> lossand non-congestive loss? I have seen some analysis that claims 
> to be
> able to differentiate between the two types of loss, but it is not 
> clear(to me) if this is assumed in this case.
> 
> acceleration flows can't cause congestive loss in a video flow - 
> eitherthrough admission control or by using different QOS markings 
> for the two

Peilin: The behavior of optimizing acceleration rate is driven by packet loss. In fact the rapid synchronization RTP multicast sessions will apply to various network conditions including admission control and QoS as you said. I have tested the model with the optimum acceleration rate in the different network conditions. The Error resilience mechanism should enable a small packet loss which may help with the case when raising the rate may ca
use packet loss.
The rapid acceleration synchronization is temporary. It is considerable whether network providers are willing to design admission control policy only for rapid acceleration synchronization. My view is that it is more appropriate for rapid acceleration synchronization to contend the bandwidth resources.If admission control is considered, I think, its policy cannot be only for rapid acceleration synchronization. Maybe per home has a sort of p
olicy. In addition, my view is that we cannot assume a model that only works when admission control and QoS are used.  

> In steps 6-7, there appears to be a deterministic round-trip-time 
> delaybetween the sender catching up to realtime and the cessation 
> of the

Peilin: Yes, you are right, it is possible one or more of the packets in the handshake are dropped. This issue surely happened in the test though its probability is very low. In order to reduce the probability of the packets, once unicast burst media stream is synchronized with multicast media stream, RS will first decreases its transmitting bitrate to a lower rate, and then send the shandshake message to RS to join the multicast session an
d terminate the unicast burst media stream. In case the shandshake message still loses,the lower rate can hint the RS to join the multicast session and terminate the unicast burst media stream. 

> 
> In step 10, the receiver assumes that the steady state found in 
> previousmulticast synchronization attempts is a good starting 
> point. I am also
> bandwidth resources. In some cases, the video is from the same QOS 
> poolas acceleration bandwidth and is thus subject to admission 
> control. In
> this case, the maximum rate can be determined directly. In other 
> cases,the video is in a different (hopefully higher) QOS pool than the
> with other (presumably rate-adaptive) flows. When contending with 
> otherrate adaptive flows, it is not clear that the available 
> bandwidth of the

Peilin: I consider the issue many times and also want to look for a better way. But I cannot. Because in the test I found that the steady state known in previous multicast synchronization attempts can meet bitrate and reduce too much loss due to the change of the conditions. But It cannot avoid the case of packets loss when user's request of multicast synchronization has long interval and the conditions also changes. I also consider an aver
age speed instead of the last optimum speed. But It seems not better than the last optimum speed. 

> http://tools.ietf.org/id/draft-peilin-avt-rtp-burst-00.txt is 
> discussingthe same topic.
>