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

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Tue, 11 Jan 2011 16:19:26 +0100

>It would be quite helpful to have it available for the upcoming SA4 meeting.

Thomas, there wasn't any update nor any ECN contribution to SA4#62 this week, right?

Thanks,
Albrecht

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Belling, Thomas (NSN - DE/Munich)
Sent: Dienstag, 21. Dezember 2010 18:26
To: IETF AVT WG; Magnus Westerlund
Subject: [AVT] draft-ietf-avt-ecn-for-rtp: Is AVPF required for leap-of-faith initialisation?

Dear Magnus,

allow me to continue a discussion we had about a month ago.

You were suggesting that the leap of faith initialisation method requires AVPF because this allows XR ECN summary reports can then be sent quicker and shorter reporting interval than the average 5secs can be negotiated. Correct?

The draft contains the following related procedure in 6.2.3:

   If the sender marks all packets as ECT while transmitting on a path

   that contains an ECN-blocking middlebox, then receivers downstream of

   that middlebox will not receive any RTP data packets from the sender,

   and hence will not consider it to be an active RTP SSRC.  The sender

   can detect this and revert to sending packets without ECT marks,

   since RTCP SR/RR packets from such receivers will either not include

   a report for sender's SSRC, or will report that no packets have been

   received, but this takes at least one RTCP reporting interval.  It

   should be noted that a receiver might generate its first RTCP packet

   immediately on joining a unicast session, or very shortly after

   joining a RTP/AVPF session, before it has had chance to receive any

   data packets.  A sender that receives RTCP SR/RR packet indicating

   lack of reception by a receiver SHOULD therefore wait for a second

   RTCP report from that receiver to be sure that the lack of reception

   is due to ECT-marking.  Since this recovery process can take several

   tens of seconds, during which time the RTP session is unusable for

   media, it is NOT RECOMMENDED that the leap-of-faith ECT initiation

   method be used in environments where ECN-blocking middleboxes are

   likely to be present.

So there is no particular trigger for the receiver to sent SR/RR reports that would allow it to benefit from the more flexible timing rules of AVPF.

One could think about using the AVPF early RTCP feedback if the sender does not receive any packets for a while at call setup, but the duration is quite open and it might also be part of normal operation that no packets are received - consider early media that are usually only transmitted in backward direction as an example.

You suggested to negotiate a higher RTCP transmission rate as a remedy. In my understanding this would work both with AVP and AVPF using SDP RTCP bandwidth modifiers.

But I am not convinced this is a good idea given the extra required bandwidth. There is a clear wording already that the leap of faith method is not  recommended in environments where ECN-blocking middleboxes are likely to be present. It is really meant for operator controlled environments where such problems will hardly occur. Is it really worth spending more bandwidth to improve the handling of a very unlikely event? If there is a real risk that ECN-marked packets are blocked in a network, other initialisation methods are preferable anyway.

As said, I also still doubt that you would have any benefit from AVPF for that initialisation method. But even I only fail to understand the advantages you had in mind (do you assume some particular receiver behaviour described nowhere up to now?),  I doubt this would be worth the extra complexity, only to improve  the handling of a very unlikely error. Again, in an network where there is a real risk that ECN-marked packets are blocked, other initialisation methods are preferable anyway.

As an unrelated question, are you working on an update of the draft?

It would be quite helpful to have it available for the upcoming SA4 meeting. I would also welcome if you could share the draft with me for a quick review before distributing it further, at least if time allows.

Regards, Thomas

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 11 Jan 2011 18:03:56 +0100

Please see some response at the bottom.

Magnus

Belling, Thomas (NSN - DE/Munich) skrev 2010-12-21 18:25:
> Dear Magnus,
> 
> allow me to continue a discussion we hadabout a month ago.
> 
> Youwere suggesting that the leap of faith initialisation method requires
> AVPF becausethis allows XR ECN summary reports can then be sent quicker
> and shorter reportingintervalthan the average 5secs canbe
> negotiated.Correct?
> 
> The draft contains the following relatedprocedurein6.2.3:
> 
> So there is noparticulartrigger for the receiver to sentSR/RR
> reportsthat would allow it to benefitfrom the more flexible timing rules
> of AVPF.
> 
> One could think about usingthe AVPFearly RTCP feedback if the sender
> does not receiveany packets for a whileat call setup, but the duration
> is quite open and it might also bepart of normal operationthat no
> packets are received–considerearly media that are usually only
> transmitted in backward direction as an example.
> 
> You suggested to negotiate a higher RTCP transmission rate as aremedy.In
> my understanding this would work both with AVP and AVPF usingSDP RTCP
> bandwidth modifiers.
> 
> But I am not convinced this is a good idea given the extra required
> bandwidth.There is a clear wordingalreadythat theleap of faith method
> isnot recommendedin environments whereECN-blocking middleboxes arelikely
> to be present. It is really meant for operator controlled environments
> where such problemswill hardly occur.Isit really worth spending more
> bandwidthto improve the handling of a very unlikelyevent?If there is a
> real risk that ECN-marked packets are blocked ina network, other
> initialisation methods are preferable anyway.
> 
> 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.
> 

On the above I will have to review the discussion and refresh myself on
our document. I will come back to you.

> As an unrelated question, are you working on an update of the draft?

The authors plan was to provide an update in December. That has clearly
failed. It is on my to do list and I do hope that we can provide one
within a few weeks.

> 
> It would be quitehelpfulto have it available for the upcoming SA4
> meeting. I would also welcome if you could share the draft with me for a
> quick review before distributing it further, at least if time allows.
> 

Sorry about that.

-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 19 Jan 2011 11:46:11 +0100

Belling, Thomas (NSN - DE/Munich) skrev 2011-01-18 11:37:
> Dear Magnus
> 
>  
> 
> I compiled the attached update proposal to the draft (with changemarks),
> adding support for a=rtcp-fb and a=rtcp-xr.
> 
> Could you please consider those changes?

Hi,

I have looked at the changes and I have the following comments:

SDP parameters. Yes, on the general level I agree this is what is
intended. On a more detailed level, I think there is a bit to much
respecification of things that are already defined.

When it comes to AVPF usage, I will go through that to try to generalize
it. I will respond separately on that.

We also have some conistency issues that needs to be fixed around
normative levels of mechanisms.

Cheers

Magnus Westerlund

---

From: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 19 Jan 2011 13:25:15 +0100

Thanks, Magnus.

My original email got blocked on the AVT exploder due to its size.
I thus resend it with a shortened attachment, showing only the parts of the draft where I propose changes. The changes are still exactly the same.

Thomas

-----Original Message-----
From: ext Magnus Westerlund [mailto:[email-masked]] 
Sent: Wednesday, January 19, 2011 11:46 AM
To: Belling, Thomas (NSN - DE/Munich)
Cc: IETF AVT WG; ext Jarvinen Kari.Ju (Nokia-NRC/Tampere); Mutikainen Jari (Nokia-MS/Helsinki); ext Leung, Nikolai; Tomas Frankkila
Subject: Re: [AVT] draft-ietf-avt-ecn-for-rtp: Is AVPF required forleap-of-faith initialisation?

Belling, Thomas (NSN - DE/Munich) skrev 2011-01-18 11:37:
> Dear Magnus
> 
>  
> 
> I compiled the attached update proposal to the draft (with 
> changemarks), adding support for a=rtcp-fb and a=rtcp-xr.
> 

Hi,

SDP parameters. Yes, on the general level I agree this is what is intended. On a more detailed level, I think there is a bit to much respecification of things that are already defined.

When it comes to AVPF usage, I will go through that to try to generalize it. I will respond separately on that.

We also have some conistency issues that needs to be fixed around normative levels of mechanisms.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 19 Jan 2011 18:06:01 +0100

> reportsthat would allow it to benefitfrom the more flexible timing rules

That is true for the case where you use leap-of-faith and have packet
dropping box in the path.

> transmitted in backward direction as an example.

No, that would be a strange special case.

> my understanding this would work both with AVP and AVPF usingSDP RTCP

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.

> initialisation methods are preferable anyway.

No, I agree that increasing the RTCP bandwidth is not the best method
here. Better utilization of the assigned resource is what should happen.
Thus AVPF.

> 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

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.

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.

Cheers

Magnus Westerlund

---

From: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 20 Jan 2011 15:50:47 +0100

Dear Magnus,

 below

> 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.

> - 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.

> have an APP packet for adjusting redundancy or number of frames in the

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.

> 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.

Regards, Thomas

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 20 Jan 2011 17:09:50 +0100

Hi Thomas,

> Remember that there are no specific triggers to send RTCP reports

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.

> 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.

> changing the codec mode reduces the bandwidth considerably without extra

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.

> 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