Subject: [AVT] Does draft-ietf-avt-ecn-for-rtp require new value for RFC 4585 "rtcp-fb" attribute ?

From: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 5 Nov 2010 17:11:11 +0100

Dear Magnus, all,

draft-ietf-avt-ecn-for-rtp defines the new RTP/AVPF Transport Layer ECN
Feedback packet.
However, no corresponding value for the RFC 4585 "rtcp-fb" attribute is
specified.

Is that intentional?

I understand that you currently mandate that RTP/AVPF Transport Layer
ECN Feedback packet are sent if the negotiation via the new
a=ecn-capable-rtp attribute concludes that ECN is used and CE marked IP
packets are received.

You might thus regard a new value for the rtcp-fb" attribute as
redundant.

However, you would rule out in this way that the "rtcp-fb" attribute is
used to negotiate any other feedback messages in the manner intended in
RFC 4585. From RFC 4585:

   If one or more "rtcp-fb" attributes are present in a media session
   description, the RTCP receivers for the media session(s) containing
   the "rtcp-fb"

...

   o  MUST NOT use other FB messages than those listed in one of the
      "rtcp-fb" attribute lines.

As a more far-reaching comment, does it indeed make sense to mandate the
sending of the RTP/AVPF Transport Layer ECN Feedback packet if CE-marked
IP packets are encountered? For many applications, you have application
specific feedback messages as alternative, for instance the CMR for the
AMR speech codec and TMMBR for video. And the "rtcp-fb" attribute would
provide ready means to negotiate the applicable feedback messages.

Regards, Thomas

---------------------------------- 
Dr. Thomas Belling 
3GPP Standardisation
Nokia Siemens Networks 

FYI: below is the relevant text from RFC 4585.

RFC 4585                        RTP/AVPF                       July 2006

4.2.  RTCP Feedback Capability Attribute

   A new payload format-specific SDP attribute is defined to indicate
   the capability of using RTCP feedback as specified in this document:
   "a=rtcp-fb".  The "rtcp-fb" attribute MUST only be used as an SDP
   media attribute and MUST NOT be provided at the session level.  The
   "rtcp-fb" attribute MUST only be used in media sessions for which the
   "AVPF" is specified.

   The "rtcp-fb" attribute SHOULD be used to indicate which RTCP FB
   messages MAY be used in this media session for the indicated payload
   type.  A wildcard payload type ("*") MAY be used to indicate that the
   RTCP feedback attribute applies to all payload types.  If several
   types of feedback are supported and/or the same feedback shall be
   specified for a subset of the payload types, several "a=rtcp-fb"
   lines MUST be used.

   If no "rtcp-fb" attribute is specified, the RTP receivers MAY send
   feedback using other suitable RTCP feedback packets as defined for
   the respective media type.  The RTP receivers MUST NOT rely on the
   RTP senders reacting to any of the FB messages.  The RTP sender MAY
   choose to ignore some feedback messages.

   If one or more "rtcp-fb" attributes are present in a media session
   description, the RTCP receivers for the media session(s) containing
   the "rtcp-fb"

   o  MUST ignore all "rtcp-fb" attributes of which they do not fully
      understand the semantics (i.e., where they do not understand the
      meaning of all values in the "a=rtcp-fb" line);

   o  SHOULD provide feedback information as specified in this document
      using any of the RTCP feedback packets as specified in one of the
      "rtcp-fb" attributes for this media session; and

   o  MUST NOT use other FB messages than those listed in one of the
      "rtcp-fb" attribute lines.

   When used in conjunction with the offer/answer model [8], the offerer
   MAY present a set of these AVPF attributes to its peer.  The answerer
   MUST remove all attributes it does not understand as well as those it
   does not support in general or does not wish to use in this
   particular media session.  The answerer MUST NOT add feedback
   parameters to the media description and MUST NOT alter values of such
   parameters.  The answer is binding for the media session, and both
   offerer and answerer MUST only use feedback mechanisms negotiated in
   this way.  Both offerer and answerer MAY independently decide to send
   RTCP FB messages of only a subset of the negotiated feedback
   mechanisms, but they SHOULD react properly to all types of the
   negotiated FB messages when received.

   RTP senders MUST be prepared to receive any kind of RTCP FB messages
   and MUST silently discard all those RTCP FB messages that they do not
   understand.

---

From: Magnus Westerlund <[email-masked]>
Date: Sat, 06 Nov 2010 02:06:15 +0100

Hi Thomas,

Belling, Thomas (NSN - DE/Munich) skrev 2010-11-05 17:11:
> Dear Magnus,all,
> 
> 
> draft-ietf-avt-ecn-for-rtpdefines the newRTP/AVPF Transport Layer ECN
> Feedback packet.
> 
> However, no corresponding value for the RFC 4585“rtcp-fb" attributeis
> specified.
> 
> Is that intentional?

No, it is not intentional, it should be there. We need both FB and XR
parameters to indicate our extensions.

> 
> 
> I understand that you currently mandate that RTP/AVPF Transport Layer ECN
> Feedback packetare sentif the negotiation via the
> newa=ecn-capable-rtpattribute concludes that ECN is usedand CE marked IP
> packets are received.
> 
> You might thus regard a new value for thertcp-fb" attributeas redundant.
> 

No, I fully agree that it is needed to be included. We also have the
receiver based CC use case where FB is not required to be used, only the
XR format. Thus one need to indicate what one do intended to use.

> However, you would rule out in this way that the“rtcp-fb" attributeis
> RFC 4585.From RFC 4585:
> As a more far-reaching comment, does it indeed make sense tomandatethe
> sendingof theRTP/AVPF Transport Layer ECN Feedback packetif CE-marked IP
> packets are encountered? For many applications, you have application
> specific feedback messages as alternative, forinstancethe CMR forthe AMR
> speech codec andTMMBRfor video. And the“rtcp-fb" attributewould provide
> ready means to negotiatethe applicable feedback messages.

The draft currently defines that in cases when you have receiver driven
congestion control then you can skip to use the FB message.

But to summarize, we simply have forgotten to add the SDP parameters for
XR and FB attributes. This will be fixed in the next version.

Cheers

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: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Sun, 7 Nov 2010 20:53:49 +0100

Hello Magnus,

> The draft currently defines that in cases when you have receiver driven congestion control then you
> can skip to use the FB message.

While I would welcome such a statement, I failed to find it in the draft.
Quite to the contrary, there are statements that seem to mandate the FB message:

6.3.2.  Reporting ECN Feedback via RTCP

   An RTP receiver that receives a packet with an ECN-CE mark, or that
   detects a packet loss, MUST schedule the transmission of an RTCP ECN
   feedback packet as soon as possible (subject to the constraints of
   [RFC4585] and [RFC3550]) to report this back to the sender.

Perhaps there is more room for improvement in the next revision.

I also noticed that in some places you only recommend AVPF (for instance in 6.3.2, although in my understanding the ECN Feedback really requires it) but in others you mandate it (which is not so compelling if ECN Feedback is not used).
A reasonable message could be that AVPF is recommended and mandated if ECN feedback is used.

Thomas

-----Original Message-----
From: ext Magnus Westerlund [mailto:[email-masked]] 
Sent: Saturday, November 06, 2010 2:06 AM
To: Belling, Thomas (NSN - DE/Munich)
Cc: IETF AVT WG; ext Jarvinen Kari.Ju (Nokia-NRC/Tampere); ext Mutikainen Jari (Nokia-MS/Helsinki); Tomas Frankkila; Schmidt, Christian 1. (NSN - DE/Munich); [email-masked]
Subject: Re: Does draft-ietf-avt-ecn-for-rtp require new value for RFC 4585 "rtcp-fb" attribute ?

Hi Thomas,

Belling, Thomas (NSN - DE/Munich) skrev 2010-11-05 17:11:
> However, no corresponding value for the RFC 4585"rtcp-fb" attributeis 
> specified.
> 
> Is that intentional?

No, it is not intentional, it should be there. We need both FB and XR parameters to indicate our extensions.

> ECN Feedback packetare sentif the negotiation via the 
> newa=ecn-capable-rtpattribute concludes that ECN is usedand CE marked 
> IP packets are received.
> 

No, I fully agree that it is needed to be included. We also have the receiver based CC use case where FB is not required to be used, only the XR format. Thus one need to indicate what one do intended to use.

> However, you would rule out in this way that the"rtcp-fb" attributeis 
> used to negotiate any other feedback messages in the manner intended 
> in RFC 4585.From RFC 4585:
> 
> sendingof theRTP/AVPF Transport Layer ECN Feedback packetif CE-marked 
> IP packets are encountered? For many applications, you have 
> application specific feedback messages as alternative, forinstancethe 
> CMR forthe AMR speech codec andTMMBRfor video. And the"rtcp-fb" 
> attributewould provide ready means to negotiatethe applicable feedback messages.

The draft currently defines that in cases when you have receiver driven congestion control then you can skip to use the FB message.

But to summarize, we simply have forgotten to add the SDP parameters for XR and FB attributes. This will be fixed in the next version.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 08 Nov 2010 09:15:15 +0800

> Perhaps there is more room for improvement in the next revision.

I think you should have continued reading that section. Later in that
section the following paragraph exists:

   In case a receiver driven congestion control algorithm is to be used
   and has been agreed upon through signalling, the algorithm MAY
   specify that the immediate scheduling (and later transmission) of
   ECN-CE feedback of any received ECN-CE mark is not required and shall
   not be done (since it is not necessary for congestion control
   purposes in such cases).  In that case ECN feedback is only sent
   using regular RTCP reports for verification purpose and in response
   to the initiation process ("rtp") of any new media senders as
   specified in Section 6.2.1.

> A reasonable message could be that AVPF is recommended and mandated if ECN feedback is used.

It is mandate, I think where we recommend it is written in a
motivational style. But that I think is part of the comments that Bob
Briscoe provided that it is not really tight as a specification. So, yes
this will be clarified. But, we don't see this working without AVPF due
to RTCP timing requirements.

Cheers

Magnus Westerlund

---

From: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 8 Nov 2010 02:43:36 +0100

Thanks, Magnus

I indeed did not notice that.

For my taste, this is still in a bit of contradiction with the text I quoted. Perhaps a SHOULD or "SHALL, unless" up there would help.

As a comment to the text you quoted, the likely feedback mechanisms (CMR, TMMBR) where specified before, so expecting ECN related considerations in those specs is a bit unrealistic.

I also mostly agree you require AVPF, but AMR with CMR in RTP could be a counterexample assuming you do not use ECN RTCP feedback.

Thomas

-----Ursprüngliche Nachricht-----
Von: ext Magnus Westerlund [mailto:[email-masked]] 
Gesendet: Montag, 8. November 2010 02:15
An: Belling, Thomas (NSN - DE/Munich)
Cc: IETF AVT WG; ext Jarvinen Kari.Ju (Nokia-NRC/Tampere); ext Mutikainen Jari (Nokia-MS/Helsinki); Tomas Frankkila; Schmidt, Christian 1. (NSN - DE/Munich); [email-masked]
Betreff: Re: Does draft-ietf-avt-ecn-for-rtp require new value for RFC 4585 "rtcp-fb" attribute ?

Belling, Thomas (NSN - DE/Munich) skrev 2010-11-08 03:53:
> Hello Magnus,
> 
>> The draft currently defines that in cases when you have receiver 
>> driven congestion control then you can skip to use the FB message.
> 

I think you should have continued reading that section. Later in that section the following paragraph exists:

> A reasonable message could be that AVPF is recommended and mandated if ECN feedback is used.

It is mandate, I think where we recommend it is written in a motivational style. But that I think is part of the comments that Bob Briscoe provided that it is not really tight as a specification. So, yes this will be clarified. But, we don't see this working without AVPF due to RTCP timing requirements.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 08 Nov 2010 18:52:26 +0800

> For my taste, this is still in a bit of contradiction with the text I quoted. Perhaps a SHOULD or "SHALL, unless" up there would help.

Yes, we can clarify that in the next version.

> As a comment to the text you quoted, the likely feedback mechanisms (CMR, TMMBR) where specified before, so expecting ECN related considerations in those specs is a bit unrealistic.
I am not certain I do understand this comment, but guessing. AMR CMR was
intended for CS interworking, not really IP level adaptation. Also TMMBR
is not a great match for adaptation for various reasons. Even if they
are being used in a session that session can definitely be used with
sender driven congestion control.

I do know that 3GPP is using CMR for speech adaptation over IP/UDP/RTP.
If 3GPP wants to use ECN in a receiver driven congestion control mode,
then they need to define that and ensure that the nodes have a behavior
that is the expected.

> I also mostly agree you require AVPF, but AMR with CMR in RTP could be a counterexample assuming you do not use ECN RTCP feedback.

Even in Receiver driven feedback you do need to send the XR ECN summary
block. Otherwise the verification and fault detection doesn't work.
Using only AVP basically results in this being sent only every 5
seconds, which is to seldom in most cases, especially during initiation
phase.

Cheers

Magnus Westerlund

---

From: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 8 Nov 2010 12:06:18 +0100

Thanks Magnus,

I would welcome if you keep me in the loop when you start working on a revision.

> Even in Receiver driven feedback you do need to send the XR ECN summary block. Otherwise the verification and fault detection doesn't work.
> Using only AVP basically results in this being sent only every 5 seconds, which is to seldom in most cases, especially during initiation phase.

Does this also apply for the leap-of-faith initialisation method used by 3GPP?
After the initialisation you can probably not send reports more frequently than every 5sec anyway without violating RTCP bandwidth constraints.

Thomas

-----Original Message-----
From: ext Magnus Westerlund [mailto:[email-masked]] 
Sent: Monday, November 08, 2010 11:52 AM
To: Belling, Thomas (NSN - DE/Munich)
Cc: IETF AVT WG; ext Jarvinen Kari.Ju (Nokia-NRC/Tampere); ext Mutikainen Jari (Nokia-MS/Helsinki); Tomas Frankkila; Schmidt, Christian 1. (NSN - DE/Munich); [email-masked]
Subject: Re: AW: Does draft-ietf-avt-ecn-for-rtp require new value for RFC 4585 "rtcp-fb" attribute ?

> As a comment to the text you quoted, the likely feedback mechanisms (CMR, TMMBR) where specified before, so expecting ECN related considerations in those specs is a bit unrealistic.
I am not certain I do understand this comment, but guessing. AMR CMR was intended for CS interworking, not really IP level adaptation. Also TMMBR is not a great match for adaptation for various reasons. Even if they are being used in a session that session can definitely be used with sender driven congestion control.

I do know that 3GPP is using CMR for speech adaptation over IP/UDP/RTP.
If 3GPP wants to use ECN in a receiver driven congestion control mode, then they need to define that and ensure that the nodes have a behavior that is the expected.

> I also mostly agree you require AVPF, but AMR with CMR in RTP could be a counterexample assuming you do not use ECN RTCP feedback.

Even in Receiver driven feedback you do need to send the XR ECN summary block. Otherwise the verification and fault detection doesn't work.
Using only AVP basically results in this being sent only every 5 seconds, which is to seldom in most cases, especially during initiation phase.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 08 Nov 2010 23:06:26 +0800

> After the initialisation you can probably not send reports more frequently than every 5sec anyway without violating RTCP bandwidth constraints.

Yes, it also applies to the leap of faith method. You will always use
the XR ECN summary report to have the sender verify that the forward ECN
path works.

When it comes to bandwidth I think the MTSI bandwidth for RTCP is
allowing more frequent regular reports than every 5 seconds. The regular
report are actually important to have the control over when they are
sent. That is why AVPF is required.

AVPF is also a question of interoperbility for ECN solution. If 3GPP
wants to completely be non-interoperable with the IETF solution you
could do anything, but please don't claim interoperability with this RFC.

Cheers

Magnus Westerlund

---

From: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 8 Nov 2010 16:38:09 +0100

> Yes, it also applies to the leap of faith method. You will always use the XR ECN summary report to have the sender verify that the forward ECN path works.

Is there any wording that the receiver sends the XR ECN summary report earlier in the beginning? Otherwise AVPF would not help.

During the operation, I would expect that the receiver sends the XR ECN summary report at regular intervals and uses other mechanism for immediate feedback.

> When it comes to bandwidth I think the MTSI bandwidth for RTCP is allowing more frequent regular reports than every 5 seconds. The regular report are actually important to have the control over when they are sent. That is why AVPF is required

I always thought bandwidth and overall reporting frequency for AVP and AVPF is the same, and AVPF only allows to react immediately should there be a need for quick feedback?

> AVPF is also a question of interoperability for ECN solution.

AVPF is negotiated using SDP, ECN is negotiated using SDP. This could be part of the answer.
I understand that clients should not be loaded with too many options. But we are quite safe to assume that every client supports AVP.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Magnus Westerlund
Sent: Monday, November 08, 2010 4:06 PM
To: Belling, Thomas (NSN - DE/Munich)
Cc: ext Jarvinen Kari.Ju (Nokia-NRC/Tampere); [email-masked]; ext Mutikainen Jari (Nokia-MS/Helsinki); Tomas Frankkila; IETF AVT WG
Subject: Re: [AVT] Does draft-ietf-avt-ecn-for-rtp require new value for RFC 4585 "rtcp-fb" attribute ?

> After the initialisation you can probably not send reports more frequently than every 5sec anyway without violating RTCP bandwidth constraints.

Yes, it also applies to the leap of faith method. You will always use the XR ECN summary report to have the sender verify that the forward ECN path works.

When it comes to bandwidth I think the MTSI bandwidth for RTCP is allowing more frequent regular reports than every 5 seconds. The regular report are actually important to have the control over when they are sent. That is why AVPF is required.

AVPF is also a question of interoperbility for ECN solution. If 3GPP wants to completely be non-interoperable with the IETF solution you could do anything, but please don't claim interoperability with this RFC.

Cheers

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]
----------------------------------------------------------------------
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 09 Nov 2010 10:27:37 +0800

> Is there any wording that the receiver sends the XR ECN summary report earlier in the beginning? Otherwise AVPF would not help.

No, there are no special consideration for this currently, as FB packet
is expected to be used for soonest possible reporting. There are no
special consideration for receiver driven here, and FB should be used
during initation phase as currently described.

> During the operation, I would expect that the receiver sends the XR ECN summary report at regular intervals and uses other mechanism for immediate feedback.

Yes, for the ongoing use, we do expect regular reports.

> I always thought bandwidth and overall reporting frequency for AVP and AVPF is the same, and AVPF only allows to react immediately should there be a need for quick feedback?

No, it is not that simple. AVPF has much more knobs for configuring RTCP
behavior, including regular reports. It also allows the negotiation of
the minimal reporting interval so that it isn't 5 seconds.

> I understand that clients should not be loaded with too many options. But we are quite safe to assume that every client supports AVP.

Well, a fixed minimal interval of 5 seconds for RTCP reporting is far
from ideal for ECN for RTP. And the way of getting away from this is to
use AVPF. This combined with the need for sender driven to use early or
immediate feedback makes it in our eyes very reasonable to mandate AVPF
for ECN.

Cheers

Magnus Westerlund