Subject: [AVTCORE] draft-ietf-avtcore-ecn-for-rtp-00.txt: What to do if "ecn-fb" has not been negotiated via rtcp.fb attribute?

From: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 11 Feb 2011 20:38:09 +0100

Dear Magnus,

You omitted one more clarification I suggested for the "rtcp-fb"
attribute negotiation procedures:

I suggested a recommendation for the case that "rtcp-fb" attribute
negotiation procedures concluded that "ecn-fb" is not allowed to use
application specific feedback when ECT marked packets are received.

Did you intentionally omit this (why?) or was it simply take away with
proposed text you considered redundant?

Thomas

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

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 15 Feb 2011 10:16:06 +0100

Belling, Thomas (NSN - DE/Munich) skrev 2011-02-11 20:38:
> Dear Magnus,
> 
> You omitted one more clarification I suggested for the“rtcp-fb”attribute
> negotiation procedures:
> 
> I suggested a recommendationfor the case
> that“rtcp-fb”attributenegotiation procedures concludedthat“ecn-fb”is not
> allowedto use application specific feedbackwhen ECT marked packets are
> received.
> 
> Did you intentionallyomitthis(why?)or was it simply take away
> withproposedtextyou considered redundant?
> 

Thomas,

I don't understand which case you are discussing. Can you please clarify
which part of the avtcore-ecn-for-rtp-00 you are refering to and what
your suggested change in relation to this would be?

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: Tue, 15 Feb 2011 13:50:53 +0100

Dear Magnus,

a possible text proposal is below (between >>> <<<):

6.2.  RTCP Feedback SDP Parameter

   A new "nack" feedback parameter "ecn" is defined to indicate the
   usage of the RTCP ECN feedback packet format (Section 5.1).  The ABNF
   [RFC5234] definition of the SDP parameter extension is:

   rtcp-fb-nack-param  = <See section 4.2 of RFC 4585>
   rtcp-fb-nack-param /= ecn-fb-par
   ecn-fb-par          = SP "ecn"

   The offer/answer rules for this SDP feedback parameters are specified
   in AVPF [RFC4585].
If ECN has been negotiated according to clause 6.1, but no "a=rtcp-fb" attribute with value "ecn" is contained in the answer, an RTP receiver that receives a packet with an ECN-CE mark SHOULD use application specific feedback.
<<<

Thomas

-----Original Message-----
From: ext Magnus Westerlund [mailto:[email-masked]] 
Sent: Tuesday, February 15, 2011 10:16 AM
To: Belling, Thomas (NSN - DE/Munich)
Cc: IETF AVT WG
Subject: Re: draft-ietf-avtcore-ecn-for-rtp-00.txt: What to do if "ecn-fb" has not been negotiated via rtcp.fb attribute?

Belling, Thomas (NSN - DE/Munich) skrev 2011-02-11 20:38:
> Dear Magnus,
> 
> You omitted one more clarification I suggested for 
> the"rtcp-fb"attribute negotiation procedures:
> 
> that"rtcp-fb"attributenegotiation procedures concludedthat"ecn-fb"is 
> not allowedto use application specific feedbackwhen ECT marked packets 
> are received.
> 

Thomas,

I don't understand which case you are discussing. Can you please clarify which part of the avtcore-ecn-for-rtp-00 you are refering to and what your suggested change in relation to this would be?

Cheers

Magnus Westerlund

---

From: ken carlberg <[email-masked]>
Date: Tue, 15 Feb 2011 08:27:32 -0500

Thomas,

> If ECN has been negotiated according to clause 6.1, but no "a=rtcp-fb" attribute with value "ecn" is contained in the answer, an RTP receiver that receives a packet with an ECN-CE mark SHOULD use a…

the above seems incomplete, and still a little complex because of what appears to be several variations of attributes.  what are you suggesting are the courses of action if "ecn" (as you describe above) *is* contained in the answer?

-ken

---

From: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 15 Feb 2011 14:37:18 +0100

Dear Ken,

I made a proposal having more wording on the negotiation procedure
earlier, but Magnus had concerns that much is redundant compared to RFC
4585 procedures. Those indeed cover this case and say that ECN-FB may
then be used.
Also, in other places in the draft there is more wording on using ECN FB
already.

I believe that the text I propose goes a bit beyond RFC 4585, because
while it is clear that other application specific feedback can be used
if negotiated, it is unclear that it should be used in response to
ECT-marked packages. Further, not all application specific feedback is
negotiated using RFC 4585.

Thomas

-----Original Message-----
From: ext ken carlberg [mailto:[email-masked]] 
Sent: Tuesday, February 15, 2011 2:28 PM
To: Belling, Thomas (NSN - DE/Munich)
Cc: ext Magnus Westerlund; IETF AVT WG
Subject: Re: [AVTCORE] draft-ietf-avtcore-ecn-for-rtp-00.txt: What to do
if "ecn-fb" has not been negotiated via rtcp.fb attribute?

Thomas,

> If ECN has been negotiated according to clause 6.1, but no "a=rtcp-fb"
attribute with value "ecn" is contained in the answer, an RTP receiver
that receives a packet with an ECN-CE mark SHOULD use application
specific feedback.

the above seems incomplete, and still a little complex because of what
appears to be several variations of attributes.  what are you suggesting
are the courses of action if "ecn" (as you describe above) *is*
contained in the answer?

-ken

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 18 Feb 2011 10:18:01 +0100

Hi Thomas,

The semantics of what your propose doesn't make sense. The "rtcp-fb"
parameter is intended to signal feedback parameters that are intended or
requested to be used. What you are proposing is to use this SDP
parameter to indicate that you are not using an RTCP FB format but
something else. The logical choice here is to use positive explicit
signaling of the alternative feedback that one uses and not indicate the
ECN FB format.

cheers

Magnus

-- 

Magnus Westerlund

---

From: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 18 Feb 2011 10:29:55 +0100

Hi Magnus,

suppose that support of TMMBR is indicated in the "rtcp-fb" attribute (in a positive way, as you suggest), but support is "ECN FB" is not indicated.

It is then clear from rtcp-fb negotiation rules that TMMBR can be used, but no ECN FB.

What is unclear is a host supporting ECN would use TMMBR when receiving ECT-marked packets.

I intended to recommend that with the proposed wording. And I believe such a recommendation could be in scope of the ECN draft (not being explicit about TMMBR, but speaking about application specific feedback in general.

Thomas

-----Original Message-----
From: ext Magnus Westerlund [mailto:[email-masked]] 
Sent: Friday, February 18, 2011 10:18 AM
To: Belling, Thomas (NSN - DE/Munich)
Cc: ext ken carlberg; IETF AVT WG
Subject: Re: [AVTCORE] draft-ietf-avtcore-ecn-for-rtp-00.txt: What to do if "ecn-fb" has not been negotiated via rtcp.fb attribute?

Hi Thomas,

The semantics of what your propose doesn't make sense. The "rtcp-fb"
parameter is intended to signal feedback parameters that are intended or requested to be used. What you are proposing is to use this SDP parameter to indicate that you are not using an RTCP FB format but something else. The logical choice here is to use positive explicit signaling of the alternative feedback that one uses and not indicate the ECN FB format.

cheers

Magnus

Belling, Thomas (NSN - DE/Munich) skrev 2011-02-15 14:37:
> Also, in other places in the draft there is more wording on using ECN 
> FB already.
> 
> Subject: Re: [AVTCORE] draft-ietf-avtcore-ecn-for-rtp-00.txt: What to 
> do if "ecn-fb" has not been negotiated via rtcp.fb attribute?
> 
> Thomas,
> 
> appears to be several variations of attributes.  what are you 
> suggesting are the courses of action if "ecn" (as you describe above) 
> *is* contained in the answer?
> 
> -ken
> 

-- 

Magnus Westerlund

---

From: ken carlberg <[email-masked]>
Date: Sun, 20 Feb 2011 07:58:57 -0500

Thomas,

the objective of the draft is to negotiate support of ECN, and then to convey the presence/reception of CE marked IP packets quickly to the source.  and the fundamental aspect of the latter is that there is a consistency in the response.  hence, if the draft becomes an RFC, then those that claim conformance know exactly what to expect and when to expect it in terms of a response to upstream congestion.

The more open ended approach that you are advocating of either ECN reports or some other application-specific feedback does away with that consistency.  Magnus raised the point that such an approach leads to non-interoperability.  In the unicast, its probably not an issue, but its not clear to me how you reconcile the multicast case.  Outside of that, its the uniformity of the response that is my bigger concern.  With application-specific responses, you cannot guarantee that the feedback of CE marked packets will exhibit the same characteristics or information.  An analogy would be like having different rules for TCP Tahoe and Reno in conveying CE back to the sender (e.g., one sends back ECN-echo in the first Ack, the other sets a different flag and sends it on the N'th Ack, or on the next upstream data packet).

If its that critical for you to have a more open-ended application specific approach in providing feedback to CE marked IP packets, then  I think it would be better to produce a separate draft articulating this design.

cheers,

-ken

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 21 Feb 2011 11:37:00 +0100

> It is then clear from rtcp-fb negotiation rules that TMMBR can be used, but no ECN FB.

Yes, I think so. And if it isn't clear then it is more a problem with
RFC 4585 than this specification.

> What is unclear is a host supporting ECN would use TMMBR when receiving ECT-marked packets.

Well, that is because we aren't defining the 3GPP TS 26.114 solution in
our specifications. This draft currently do require for interoperability
that you do support the ECN feedback format and the XR summary format as
well as the RTP/RTCP based initiation method.

If 3GPP selects to be non compliant to this and ignores the desire for
interoperability, I think it is primarily the 3GPP's issue to ensure
that their signalling ensures that TS 26.114 compliant terminals will
negotiate this correctly.

> I intended to recommend that with the proposed wording. And I believe such a recommendation could be in scope of the ECN draft (not being explicit about TMMBR, but speaking about application specif…

I don't think it is that appropriate. What I think we can clarify
further is the need for mechanisms using additional signalling or
specific congestion control algorithms the need to define thier own
signalling to ensure compatibility between enabled end-points.

Cheers

Magnus Westerlund

---

From: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 23 Feb 2011 03:07:13 +0100

Hi Magnus,

please note that the agreed procedures in TS 26.114 currently do not assume the behaviour discussed in this thread from peers, as we deemed it safer not to take any such assumptions.

Although the question poped up when we were preparing the procedures.

So you believe such a recommendation is not appropriate?

Thomas

-----Original Message-----
From: ext Magnus Westerlund [mailto:[email-masked]] 
Sent: Monday, February 21, 2011 11:37 AM
To: Belling, Thomas (NSN - DE/Munich)
Cc: ext ken carlberg; IETF AVT WG
Subject: Re: [AVTCORE] draft-ietf-avtcore-ecn-for-rtp-00.txt: What to do if "ecn-fb" has not been negotiated via rtcp.fb attribute?

> It is then clear from rtcp-fb negotiation rules that TMMBR can be used, but no ECN FB.

Yes, I think so. And if it isn't clear then it is more a problem with RFC 4585 than this specification.

> What is unclear is a host supporting ECN would use TMMBR when receiving ECT-marked packets.

Well, that is because we aren't defining the 3GPP TS 26.114 solution in our specifications. This draft currently do require for interoperability that you do support the ECN feedback format and the XR summary format as well as the RTP/RTCP based initiation method.

If 3GPP selects to be non compliant to this and ignores the desire for interoperability, I think it is primarily the 3GPP's issue to ensure that their signalling ensures that TS 26.114 compliant terminals will negotiate this correctly.

> I intended to recommend that with the proposed wording. And I believe such a recommendation could be in scope of the ECN draft (not being explicit about TMMBR, but speaking about application specif…

I don't think it is that appropriate. What I think we can clarify further is the need for mechanisms using additional signalling or specific congestion control algorithms the need to define thier own signalling to ensure compatibility between enabled end-points.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 23 Feb 2011 09:12:22 +0100

> So you believe such a recommendation is not appropriate?

I think there can be an informative pointer to that in advanced use case
beyond what is defined in here, it is important to watch the RTCP-FB
attribute for what messages really should be used in a session.

Cheers

Magnus Westerlund