Re: [AVT] draft-ietf-avt-ecn-for-rtp: Is AVPF required for leap-of-faith initialisation?

[Magnus Westerlund <[e-mail]>]

Hi Thomas,


Belling, Thomas (NSN - DE/Munich) skrev 2011-01-20 15:50:
>>
>> Well, it is the minium interval value that needs to be set to
> something
>> else than 5 seconds to get better results. For AVP that is allowed but
>> no signalling exist. Using the formula for calculating the min
> interval
>> according to RFC 3550 could work.
>>
>>  o  The RECOMMENDED value for the reduced minimum in seconds is 360
>>      divided by the session bandwidth in kilobits/second.  This
> minimum
>>      is smaller than 5 seconds for bandwidths greater than 72 kb/s.
>>
>> AVPF allows one to set trr-int to a reasonable interval through
>> signalling for this case. And that is without any extreme setting of
> the
>> RTCP bandwidth. The whole point with AVPF here is to use the
> signalling
>> and improved rules to provide better RTCP functionality without
>> increasing the bandwidth.
> 
> I believe the "calculated interval" is important rather than the
> "minimum interval" which is only a lower bound for the calculated
> interval. The calculated Interval depends on number of participants and
> available bandwidth.
> Remember that there are no specific triggers to send RTCP reports
> earlier.

I wouldn't agree for most sensible settings of the RTCP bandwidth if you
are using AVP, then the minimal interval will be the limiting factor
unless there is a larger multi party group.

For example with a session bandwidht of 24 kbps then 5% bandwidth are
1200 bps. In a two party session, i.e. 2 SSRCs, then the deterministic
calculated RTCP interval becomes with the following assumptions: 200
bytes RTCP packets and both SSRCs send data. Which means they share the
full RTCP bandwidth, independent of how RS and RR is set.

n=2
C=200*8/1200

Td = max(Tmin, n*C = 2,667)

If Tmin is the default value of 5 seconds, then we can easily see that
for a point to point session we either needs twice as many session
members, double the size of the RTCP packet, or half the RTCP bandwidth
before Tmin isn't the limiting factor.

If one has a higher RTCP bandwidth without increasing the number of
session participants, the calculated Td is reduced correspondingly with
the RTCP bandwidth increase.

The whole point of this is that in MTSI type of use cases it will not be
calculated transmission interval that will be the limiting factor, it is
the default minimal interval of 5 seconds.


> 
>>>
>>> As said, I alsostilldoubt that you would have any benefit from
> AVPFfor
>>> thatinitialisationmethod.ButevenIonly failto understand the
> advantages
>>> you had in mind (do youassume some particular
> receiverbehaviourdescribed
>>> nowhere up to now?), I doubt this would beworth the extra
> complexity,
>>> only to improve the handling of a very unlikely error. Again, in
>>> annetworkwherethere is a real risk that ECN-marked packets are
> blocked,
>>> other initialisation methods are preferable anyway.
>>>
>>
>> Even with leap-of-faith you need to send the ECN indications for
> sender
>> driven, thus you need it. For receiver driven reactions, you still
> need
>> to send the control message to the sender. If that is using RTCP, it
>> still needs AVPF for allowing for earliest possible transmission.
>>
>> The only cases where I will agree that you don't need AVPF are:
>>
>> - Codec mode adaptation for AMR
> 
> This case may not be the exception but the rule in 3GPP, where it is
> agreed to send CMR in response to ECT bits for speech. AMR is used for
> speech. And speech is still more frequent than video. Thus this case
> deserves special attention.
> 


As I said before, this appears to be a real corner case:
1. It requires one to use Leap-of-faith init, anything else and the init
requires AVPF to work well.

2. Any sender based scheme congestion control algorithm needs rapid
report of CE marks, so it needs to be receiver based.

3. It needs to have a back channel that isn't RTCP based. I don't know
if anything outside of AMR, AMR-WB, EVRC and SMV has such mechanism.

I guess there are some points in that under the above restrictions it
isn't motivated by this proposal to require AVPF. We might still do it
because it is simpler to do and it is such a corner case.

>> But, in 3GPP I would argue that AVPF is still needed in this case as
> you
>> have an APP packet for adjusting redundancy or number of frames in the
>> packet.
> 
> This will not be used in response to ECT markings being received
> according to agreements in 3GPP SA4.
> In my understanding the rational is that ECT markings in 3GPP will be
> set in the radio network where IP header compression is in place. Here,
> changing the codec mode reduces the bandwidth considerably without extra
> delay.
> 

So, what is written in Section 7.3.2 in 26.114 version 9.4.0 at the end
of this section is not what is going to be used? So are you backtracking
that Rel 9 decision in Rel 10?

"For speech, RTCP APP packets are used for adaptation (see clause 10.2)."

Don't that include redundancy signalling also? Which do matter
independently if one uses cellular network with header compression or not.

>> I will look into the formulations here. If there is a large number of
>> things that are needed to be fulfilled before AVPF is not requried, it
>> is simpler to require it always. But, I will look into that we have
>> accurate statements in the draft.
> 
> Thanks a lot.
> My current proposal is to link it to the ECN RTCP FB message. Obviously
> initialisation methods using the ECN FB message then will also require
> AVPF, and this can be stated in addition.

> In a sense particular application specific feedback is out-of-scope of
> the draft but a NOTE stating that many application specific feedback
> methods also require AVPF may be helpful.

I will consider this in the editing pass and come back on this change
proposal.


Maybe we should spare AVT WG from the 3GPP SA4 discussion on this other
topic, related to if MTSI can use the above restrictions and if that
makes sense. I will however state my view here once:

1. MTSI uses RTCP for its bit-rate adaptation feedback, thus needs AVPF
even for speech only sessions.

2. AVPF has low cost and provides benefits for any RTCP handling. The
fact that one has explicit configuration of TRR-Int and the possibility
to use early mode to send important events is a great benefit. It
produces more rapid feedback when needed, and can lower the RTCP
bit-rate actually consumed.

3. Considering that you SA4 already has agreed to use AVPF in Rel9 it
seems strange to remove it in some cases in Rel 10.


Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------