Subject: [AVT] About packet loss by noise//Re: New draft on rapid synchronization

From: Peilin YANG <[email-masked]>
Date: Tue, 03 Mar 2009 12:01:24 +0800

Hi Bill,

You are right it is very difficult to exactly differentiate between congestive loss and noise/loss. Nevertheless, for noise/loss there are some inherent characteristics. We can identify them roughly.

Network noise generally includes stationary noise(such as white noise),semi-stationary noise and impulsive noise. 

In the deployed network both the stationary noise and impulsive noise cannot be avoided. The semi-stationary noise has been avoided by the SNR Margin in the deployed network.

For the stationary noise(white noise), actually the network allows the bit error rate of 1E-7 which estimates about packet loss rate of 1E-5.  
Yes, it is true that the receiver cannot differentiate between the congenstion loss and noise loss. But in the vast majority of case the congestion loss is more than 10 times than the stationary noise loss. So we can suggest a threshold(e.g 0.05％). If packet loss rate is lower than the threshold, we think it is caused by the stationary noise whether it is stationary noise or congention loss. When packet loss rate is higher than the threshol
d, it is necessary to decrease the bitrate. 

For the impulsive noise, if it is transient, physicial layer retransmission will resolve packet loss. If it is long time, access network will utilize rate adaption methods(e.g SRA[Seamless Rate Adaptation], RRA[Rapid Rate Adaptation])to decrease the bandwidth of access network to the stability, reliability of link. At this time it is necessary to adjust the bitrate.

Best 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]>

> 
> 
> 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 
> 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.
> 
> 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 - 
> eitherthrough 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 
> delaybetween 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 
> previousmulticast 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 
> 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
> acceleration data. In this case, the acceleration burst is contending
> with other (presumably rate-adaptive) flows. When contending with 
> otherrate 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 
> discussingthe same topic.
> 
> I suggest you review it and take this work into account.
> 
> Thanks
> 
> Roni Even
> 
> 
> 
> 
> 
>

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 2 Mar 2009 20:18:06 -0800

> For the stationary noise(white noise), actually the network 
> allows the bit error rate of 1E-7 which estimates about 
> packet loss rate of 1E-5.  
> Yes, it is true that the receiver cannot differentiate 
> between the congenstion loss and noise loss. But in the vast 
> majority of case the congestion loss is more than 10 times 
> than the stationary noise loss. So we can suggest a 
> threshold(e.g 0.05％). If packet loss rate is lower than the 
> threshold, we think it is caused by the stationary noise 
> whether it is stationary noise or congention loss. When 
> packet loss rate is higher than the threshol

This requires an accurate estimation for the threshold value, which does not seem easy to me.
 
> For the impulsive noise, if it is transient, physicial layer 
> retransmission will resolve packet loss. If it is long time, 
> access network will utilize rate adaption methods(e.g 
> SRA[Seamless Rate Adaptation], RRA[Rapid Rate Adaptation])to 
> decrease the bandwidth of access network to the stability, 
> reliability of link. At this time it is necessary to adjust 
> the bitrate.

Not all DSL deployments have retransmission enabled in the PHY layer. Instead they often use FEC. When the PLY layer FEC fails (due to excessive noise), the observed packet loss in the IP layer will be bursty (due to interleaving). We don't want to identify this loss event as congestive loss. Whatever algorithm is used, it needs to take care of this kind of relations.

BR,
-acbegen

>  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
> 收件人: Roni Even <[email-masked]>, Orit Levin 
> <[email-masked]>, VAN CAENEGEM Tom 
> <[email-masked]>, "Dave Oran (oran)" 
> <[email-masked]>, "Ali C. Begen (abegen)" <[email-masked]>

---

From: Peilin YANG <[email-masked]>
Date: Wed, 04 Mar 2009 16:09:52 +0800

Dear Ali,

Thank you very much for your concern. 

For the threshold value of 0.05%, I estimated it according to the following formula.
PLR = BER*1400*8/(40 or 15) = 1E-7 *1400*8/(40 or 15) = (2.8 or 7.5)*1E-5.
Meanwhile, considering the influence of transient noise so I estimated it at 0.05%. 

This is only my simple estimation. I think we can discuss an more accurate estimation value based on everyone's precious experience.  

Best regards,

Peilin

----- 原邮件 -----
发件人: "Ali C. Begen (abegen)" <[email-masked]>
日期: 星期二, 三月 3日, 2009 下午12:20
主题: RE: About packet loss by noise//Re: [AVT] New draft on rapid synchronization
收件人: Peilin YANG <[email-masked]>, "Bill Ver Steeg (versteb)" <[email-masked]>
抄送: Roni Even <[email-masked]>, Orit Levin <[email-masked]>, VAN CAENEGEM Tom <[email-masked]>, "Dave Oran (oran)" <[email-masked]>, Tom Taylor <[email-masked]>, IETF AVT WG <[email-masked]>

> Not all DSL deployments have retransmission enabled in the PHY 
> layer. Instead they often use FEC. When the PLY layer FEC fails 
> (due to excessive noise), the observed packet loss in the IP layer 
> will be bursty (due to interleaving). We don't want to identify 
> this loss event as congestive loss. Whatever algorithm is used, it 
> needs to take care of this kind of relations.
> 
> BR,
> -acbegen
> 
> > Best regards,
> > 
> > Peilin
> > 
> > > Lei. It is encouraging to see that the authors agree with the 
> broad> > methodology of the previous drafts around rapid 
> acceleration of
> > > 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?
> > > 
> > > relative merits of having a handshake (with its resultant RTT-
> scale> > delay) and pre-signaling the transition.  I am 
> particularly 
> > interested

---

From: "Jaehwan Kim" <[email-masked]>
Date: Fri, 6 Mar 2009 11:00:40 +0900

Hi Peilin,

Thank you for your explanation. 

BTW, can we know which field you consider for 0.05%?
In RTCP RR, fraction lost has just 8 bits and 256 level.

And the minimum value of RTCP RR fraction lost value is 1:
 	1/256 * 100 (%) = 0.390625%
In rtp-burst draft, SRA has also 8 bits fraction lost field.
i.e. we can't measure 0.05% if we use this field.

Maybe we should use another field?

Regards,
Jaehwan
Vidiator

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peilin YANG
Sent: Wednesday, March 04, 2009 5:10 PM
To: Ali C. Begen (abegen)
Cc: Bill Ver Steeg (versteb); Dave Oran (oran); Tom Taylor; IETF AVT WG; VAN CAENEGEM Tom
Subject: Re: [AVT] About packet loss by noise//Re: New draft on rapid synchronization

Dear Ali,

Best regards,

Peilin

----- 原邮件 -----
发件人: "Ali C. Begen (abegen)" <[email-masked]>
日期: 星期二, 三月 3日, 2009 下午12:20
主题: RE: About packet loss by noise//Re: [AVT] New draft on rapid synchronization
收件人: Peilin YANG <[email-masked]>, "Bill Ver Steeg (versteb)" <[email-masked]>
抄送: Roni Even <[email-masked]>, Orit Levin <[email-masked]>, VAN CAENEGEM Tom <[email-masked]>, "Dave Oran (oran)" <[email-masked]>, Tom Taylor <[email-masked]>, IETF AVT WG <[email-masked]>

> > > I suggest you review it and take this work into account.
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt