Re: [AVTCORE] draft-ietf-avtcore-rtp-circuit-breakers-02

[lingli deng <[e-mail]>]

Hello Colin,

To be honest, this is a really informative and well-written document.
However, I do have a couple of concerns to post.

A general one, the current algorithm is based on packet loss or equivalent
events (as indicated by ECN-CE marks) only, which is aimed at setting a
safe net for all RTP CC algorithms above. I am afraid this may result
in severe unfairness against RTP over UDP streams in wireless
accessing scenarios since:

1) There is likely to be consistent packet loss due to the unstable and
sensitive nature of wirelss channels, average 2% for stable signal and can
reach 5% on moving vehicle. Using the TCP bandwith calculation fomula in
the draft, it is expected that when packet loss rate increase from 1% to
2%, the compliant RTP streams would lose 30% bandwidth. When the rate
further increases from 2% to 5%, the limit further drops another 80%. I
would not consider that to be fair.

2) On the other hand, there have been various TCP CC algorithms to improve
TCP throughput for mobile devices. It is true that neither of them gained
prevalence in end-systems. However, it may change the picture if the
operator does something in between. Right now, China Mobile is
experimenting deploying TCP proxies to enhance downlink throughput which
basically ignores random losses. And it is common practice that DCs deploy
such proxies to enhance user experience. In other words, computing TCP
compliant bandwidth limit using Reno/NewReno may be too conservative.
ECN is helpful, but to my knowledge they are mostly unsupported or turned
off in cellular accessing networks.
It may seem reasonable to add delay based detection for the triggering the
algorithm, especially for the intial phase of the call.

An other small issue:

In section 4.4, it states "RTP flows halted by the circuit breaker SHOULD
NOT be restarted automatically unless the sender has received information
that the congestion has dissipated."]

I wonder if the RTP flows are halted there is likely to be no further
information about the congestion unless from the outside of RTP stack,
meaning in most cases no automatical restart thereafter. Is this what you
have in mind? Otherwise, some more clarification about how to acquire
further information on congeston may help.

BR

-- 
邓灵莉/Lingli Deng
中国移动通信研究院/China Mobile Research Institute
e-mail: [e-mail]
tel: [phone]
mobile: [phone]