Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04

From: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 7 Oct 2011 20:30:41 +0200

Dear all,

I checked the draft and believe it is ready for publication.

I only have a small proposal for improvement, that could be incorporated
if a revision becomes necessary due to other comments:

I noticed that you changed "must" to "should" in the Implementation
Considerations In Clause 9 when going from version 01 to 02:

    To allow the use of ECN with RTP over UDP, the RTP implementation   

    *should* be able to set the ECT bits in outgoing UDP datagrams, and

    *should* be able to read the value of the ECT bits on received UDP

    datagrams.  

After some discussions with Magnus I understand that the exception
motivating the "should" rather than a "must" is implementations only
supporting sending or receiving of unidirectional media streams. But it
would be clearer to state that explicitly, for instance by saying:

"To allow the use of ECN with RTP over UDP, an RTP implementation   

desiring to support receiving ECN controlled media streams must support
reading the value of the ECT bits on received UDP datagrams, and an RTP
implementation desiring to support sending ECN controlled media streams
must support setting the ECT bits in outgoing UDP datagrams."

Thomas Belling

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

From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext Roni Even
Sent: Friday, September 30, 2011 2:29 PM
To: [email-masked]
Subject: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04

Hi,

I would like to start a WGLC on
http://tools.ietf.org/html/draft-ietf-avtcore-ecn-for-rtp-04 , Explicit
Congestion Notification (ECN) for RTP over UDP.

The WGLC will end on October 21, 2011

Please review the draft and send comments to the list.

Roni Even

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 10 Oct 2011 11:47:06 +0200

On 2011-10-07 20:30, Belling, Thomas (NSN - DE/Munich) wrote:
> motivating the “should” rather than a “must” is implementations only

I think this a good clarification.

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: Qin Wu <[email-masked]>
Date: Tue, 11 Oct 2011 10:46:19 +0800

Hi,
I have reviewed this draft and support it moving towards publication.
Here is my minor editional comments to this 04 version draft.
1. Section 1
[Qin]:Is it better to move the first paragraph next to the third paragraph.

2. Section 3, 1st paragraph
"
   ECN has been specified for use with TCP [RFC3168], SCTP [RFC4960],
   and DCCP [RFC4340] transports. These are all unicast protocols which
   negotiate the use of ECN during the initial connection establishment
   handshake (supporting incremental deployment, and checking if ECN
   marked packets pass all middleboxes on the path). 
"
[Qin]: I think "these"  in the second sentence can't be "ECN" 
mentioned in the first sentence. Is it better to replace "these" 
the first word in this sentence with "these transport"?

"
   ECN-CE marks are
   immediately echoed back to the sender by the receiving end-point
   using an additional bit in feedback messages, and the sender then
   interprets the mark as equivalent to a packet loss for congestion
   control purposes.
"

[Qin]: For this sentence, it is not clear to me what is the  feedback message? 
Is feedback message a new RTCP Feedback message defined in this 
document or TCP message or SCTP message? If it is latter, I would like 
to change it as these transport protocols header

3. Section 3, 2nd paragraph
"
   Counting vs Detecting Congestion:  TCP and the protocols derived from
   it are mainly designed to respond the same whether they experience
   a burst of congestion indications within one RTT or just one.
"
[Qin]: What's the difference between "one RTT" and "just one"?

4. Section 3.1

[Qin]: Any requirements that should be met by the middlebox or intermediate node?

5. Section 3.2,3rd paragraph
"
   Topo-Point-to-Point:  This is a standard unicast flow.  
   ....
"

[Qin]: Topo-point-to-point is not flow but a topology. Should this sentence be
rephrased as "This is for a standard unicast flow".

"
Accordingly, we allow ECN to be used by an RTP sender using multicast UDP
provided the sender has verified that the paths to all its known receivers support ECN,
and irrespective of whether the paths from other senders to their receivers support ECN 
("all its known receivers" are all the SSRCs that the RTP sender has received RTP or RTCP
from the last five reporting intervals, i.e., they have not timed out).
"    
[Qin]: Five is default value of the timeout multiplier, do you think other value is not allowed?

"
Since only a subset  of the RTP packets generated by a sender are forwarded to the
 receivers, a video switching MCU can break ECN negotiation (the success of the 
ECN negotiation may depend on the voice activity of  the participant at the instant the
 negotiation takes place - shout  if you want ECN). 
"
   
[Qin]: Is "shout if you want ECN" appropirate language here?

6. Section 3.2, 4th paragraph
"
 This is a great benefit as the rate of an
 RTP session can be varied in a number of ways,
"
[Qin]: Should "rate" in this sentence be data rate or bitrate?

7. Section 3.2, 5th paragraph
"
The standard RTP/ AVP profile [RFC3551] does not allow any early or immediate
transmission of RTCP feedback, and has a minimal RTCP interval whose default value
 (5 seconds) is many times the normal RTT between sender and receiver.
"
[Qin]: What's the purpose of last sentence of this paragraph?
       Are you saying RFC3551 following Regular RTCP timing rule?
       or something else?

   Another question is according to RFC3551, the negotiation of
   parameters or membership control may be not support. in other wonder,
   there may be no way to negotiate ECN with RTP using SDP signaling,
   I am wondering can we say ECN with RTP can be used with the standard RTP/
   AVP profile [RFC3551]. 

8. Section 3.3,3rd paragraph
"
   For interoperability we mandate the implementation of the RTP/AVPF
   profile, with both RTCP extensions and the necessary signalling to
   support a common operations mode.  This specification recommends the
   use of RTP/AVPF in all cases as negotiation of the common
   interoperability point requires RTP/AVPF, mixed negotiation of RTP/
   AVP and RTP/AVPF depending on other SDP attributes in the same media
   block is difficult,
"
[Qin] How mixed negotiation is avoided when you don't put all the SDP attribute
 into the same media block? I don't really understand the rationale. Would you
like to clarify a little bit?

9. Section 4, 1st paragraph
"
2.  Initiation and initial verification of ECN capable transport
"
 [Qin]: It looks the bullet 2 has two steps,
 a. Initiation procedure
 b. inital verification procedure, If there is no STUN exchange in between, if the step (a) initiation procedure
 is required?

10. Section 4, 2nd paragraph
"
This document defines the information that needs to be negotiated, and provides a mapping to SDP
for use in both declarative and offer/answer contexts.
"
[Qin]: Would it be better to add an anchor pointing to the section 6.1.1 and 6.1.2?

11. Section 4, 3rd paragraph
"
   o  The sender may generate a (small) subset of its RTP data packets
      with the ECN field set to ECT(0) or ECT(1). 
"

[Qin] It is not clear to me where the ECN field is located.
Is ECN field in the IP header or UDP header or RTP header?

12. Section 5, 1st paragraph
"
   This memo defines two new RTCP extensions: one RTP/AVPF [RFC4585]
   transport layer feedback format for urgent ECN information, 
"
 [Qin]: Should the "urgent ECN information" be "urgent ECN information reporting"

13.Section 5.1,1st paragraph
"
   This RTP/AVPF transport layer feedback format is intended for use in
   RTP/AVPF early or immediate feedback modes when information needs to
   urgently reach the sender.  Thus its main use is to report reception
   of an ECN-CE marked RTP packet so that the sender may perform
   congestion control, or to speed up the initiation procedures by
   rapidly reporting that the path can support ECN-marked traffic.
"

[Qin]: are you saying slow initiation procedure may result in network congestion?
In my understanding, when ECN-CE marked packet is received, the only choice for sender
is to do congestion control since you are not sure if initiation procedure lead to such
congestion. If it is not intiation procedure that lead to congestion, you get risk to worse
congestion condition? 

14.Section 6.1, 1st paragraph
"
   One new SDP attribute, "a=ecn-capable-rtp", is defined.  This is a
   media level attribute, and MUST NOT be used at the session level.  It
   is not subject to the character set chosen.
"
 
[Qin] Would it better to put reference to the section 6 of RFC4566 for character set?

15. Sectioin 6.1, 2nd paragraph
"
   ect:  This parameter makes it possible to express the preferred ECT
      marking.  This is either "random", "0", or "1", with "0" being
      implied if not specified.  The "ect" parameter describes a
      receiver preference, and is useful in the case where the receiver
      knows it is behind a link using IP header compression, the
      efficiency of which would be seriously disrupted if it were to
      receive packets with randomly chosen ECT marks.  It is RECOMMENDED
      that ECT(0) marking be used.
"

[Qin]: It looks ect is not well specified here.
e.g.,what it means if ect is set to "random" or "1" from above paragraph. what does "randomly chosen" stand for?
I think when ect is set 0, it means ECT(0) is chosen, when ect is set 1,
it means ECT(1) is chosen, when ect is set random, it means either ECT(0) or
ECT(1) is chosen. I think it should be clear in the text.

Also I think the text like ""0" being implied if not specified" in this paragraph is not correct.

16. Section 6.1.3, 2nd paragraph
"
If timely feedback is not required it is still RECOMMENDED
to used RTP/AVPF.
"

[Qin]: Should "used" in this sentence be "use"?

17.Section 7.1,2nd paragraph
"
The "rtcp-fb" attribute with the "nack" parameter "ecn" MUST be used
whenever the initialization method or a congestion control algorithm
requiring timely sender side knowledge of received CE markings.
"
 [Qin]: Should "requiring" in this sentence be "requires"?

18.Section 7.2, 2nd paragraph
"
   At the start of the RTP session, when the first packets with ECT are
   sent, it is important to verify that IP packets with ECN field values
   of ECT or ECN-CE will reach their destination(s).  
"
[Qin]: Should "first packets" be "first packet" and "IP packets" be "IP packet"?

"
If the path between the sender and the receivers exhibits either of these behaviours one
"
[Qin]: s/the receivers/receiver

"
If the path between the sender and the receivers exhibits either of these behaviours one
 needs to stop using ECN immediately to protect both the network and
 the application.
"
 [Qin]: How does sender or receiver detects ECN is misused? Who is the
  "one" in this sentence? If it is middlebox, the middlebox should also
 tell the sender ECN is not used.

19.Section 7.2.1, 1st paragraph
"
 Then any resulting lack of congestion response is likely to have little
 damaging affect on others.  
"

[Qin] s/affect/effect

"
Note: The above optimization supports peer to peer unicast
transport with several SSRCs multiplexed onto the same flow
(e.g., a single participant with two video cameras, or SSRC
multiplexed RTP retransmission [RFC4588]).  It is desirable to
"
[Qin]: In SSRC multiplexed RTP Retransmission case, original stream and associated retransmission 
        stream possible have different
        transport characteristics, however the original stream may be multicast stream, which contradict to
        what you said about "The above optimization supports peer to peer unicast
         transport", am I wrong?
"
be able to rapidly negotiate ECN support for such a session,
but the optimisation above can fail if there are
implementations that use the same CNAME for different parts of
a distributed implementation that have different transport
characteristics (e.g., if a single logical endpoint is split
across multiple hosts). 
"
[Qin]: I don't get this example clearly. are you saying when two streams with the same CNAME 
is sent from the same RTP sender, such above optimization applies.However when two streams 
with the same CNAME are sent from two differnt RTP entities,such above optimization can not apply.

20. Section 7.2.2,1st paragraph
"
This section describes an OPTIONAL method that can be used to avoid
media impact and also ensure an ECN capable path prior to media
"
[Qin]: What's the media impact? It looks like a new term that needs to be explained 
somewhere.

21. Section 7.2.2,3rd paragraph
"
 A STUN server thatdoesn't understand the extension, or is incapable of 
 reading the ECN values on incoming STUN packets, should follow the rule in the STUN
 specification for unknown comprehension-optional attributes, and ignore the attribute,
 resulting in the sender receiving a STUN response without the ECN Check STUN attribute.

"
[Qin]: Is the sender in this sentence "the media sender" or new participant?

22. Section 7.2.2, last paragraph
"
 If that is successfully completed the ECT properties of the session are
 maintained for the other senders in the session.  
"

[Qin]: Who is the other senders? are the other senders "new participant"
 or other participants? It should be clear in the text.

23. Section 7.3, 1st paragraph
"
   Once ECN has been successfully initiated for an RTP sender, that
   sender begins sending all RTP data packets as ECT-marked, and its
   receivers send ECN feedback information via RTCP packets.  This
   section describes procedures for sending ECT-marked data, providing
   ECN feedback information via RTCP, responding to ECN feedback
   information, and detecting failures and misbehaving receivers.
"
[Qin]It looks failure detection is discussed in different section, i.e., section 7.4.
 Suggest to remove ", and detecting failures and misbehaving receivers" from this paragraph.

24. Section 7.3.1, 2nd paragraph
"
 The sender SHALL NOT include ECT marks on outgoing RTCP packets, 
"
[Qin]: Is it true, since RTP/AVPF Transport Layer ECN Feedback packet include
the satistics of ECT marks?

25. Section 7.4.1,4th paragraph
"
load balancing devices may in worst case result in that some packets take a
different network path then the others; 
"

[Qin]: Should "then" in this sentence be "than" ?

26. Section 7.4.2, 4th paragraph
"
   The rate of packet duplication is tracked, allowing one to take the
   duplication into account.  The value of the ECN field for duplicates
   will also be counted and when comparing the figures one needs to take
"
[Qin]: What and where are the figures?

27.Section 8.2,8th paragraph
"
   When rounding counter values in the translated RTCP packet, the
   translator should try to ensure that they sum to the number of RTP
   packets in the pre-translation sequence number space (numOrig).  The
   translator should also try to ensure that no non-zero counter is
   rounded to a zero value, since that will lose information that a
   particular type of event has occurred.  It is recognised that it may
   be impossible to satisfy both of these constraints; 
"

[Qin]: What's the difficulty to satisfy both constraints, why non-zero 
counter can be rounded into zero? what kind of round method is used? 
can you explain a little bit?

28.Section 8.4, 2nd paragraph
"
   An ECN-aware RTP mixer must generate RTCP ECN feedback packets and
   RTCP XR report blocks for ECN summary information relating to the RTP
   flows it terminates, in exactly the same way it would if it were an
   RTP receiver.  These reports form part of the congestion control loop
   between the mixer and the media senders generating the streams it is
   mixing.  A separate control loop runs between each sender and the
   mixer.
"
 
[Qin]: what's the difference between congestion control loop and a separate control loop 
 between media sender and mixer? are you saying congestion control loop is unidirectional?

29. Section 12,1st paragraph
"
   This section contain a few different examples of the signalling
   mechanism defined in this specification in an SDP context.  If there
   are discrepancies between these examples and the specification text,
   the specification text is definitive.
"
[Qin]: Why discrepacies is allowed? Should these example be consistent with 
the sepcification text?

30. Section 12.1
"

   This SDP offer offers a single media stream with 3 media payload
   types.  It proposes to use ECN with RTP, with the ICE based
   initialization as being preferred over the RTP/RTCP one.  Leap of
   faith is not suggested to be used.  The offerer is capable of both
   setting and reading the ECN bits.  In addition the RTCP ECN feedback
   packet is configured and the RTCP XR ECN summary report. 
"
[Qin]: Are you saying both ECN feedback and the XR ECN summary
report are allowed and configured or something else?

Regards!
-Qin

  ----- Original Message ----- 
  From: Roni Even 
  To: [email-masked] 
  Sent: Friday, September 30, 2011 8:29 PM
  Subject: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04

  Hi,

I would like to start a WGLC on http://tools.ietf.org/html/draft-ietf-avtcore-ecn-for-rtp-04 , Explicit Congestion Notification (ECN) for RTP over UDP. The WGLC will end on October 21, 2011

   

  Roni Even

------------------------------------------------------------------------------

  _______________________________________________
  Audio/Video Transport Core Maintenance
  [email-masked]
  https://www.ietf.org/mailman/listinfo/avt

---

From: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 11 Oct 2011 17:14:12 +0200

Dear Qin, Magnus,

Some replies to some of the earlier comments (I only briefly checked the
rest).

Thomas

"

"

[Thomas] Intention seems rather to be "just one congestion indication".

"

The standard RTP/ AVP profile [RFC3551] does not allow any early or
immediate
transmission of RTCP feedback, and has a minimal RTCP interval whose
default value

"

   Another question is according to RFC3551, the negotiation of
   parameters or membership control may be not support. in other wonder,
   there may be no way to negotiate ECN with RTP using SDP signaling,
   I am wondering can we say ECN with RTP can be used with the standard
RTP/
   AVP profile [RFC3551]. 

[Thomas] Negotiation is done with the 'ecn-capable-rtp' SDP attribute
defined is this draft. Implantations not supporting ECN would ignore
this, But this is independent of AVP or AVPF. 

"

"

[Qin] How mixed negotiation is avoided when you don't put all the SDP
attribute
 into the same media block? I don't really understand the rationale.
Would you
like to clarify a little bit?

[Thomas] SDP capneg allows offering AVPF and AVP in the same media
block, and also to relate SDP attributes to one of the transports only.
Trouble is that this is not yet supported everywhere and has its
problems with traversing intermediates not supporting it.

"

"

[Thomas] It is the IP header. Text could be modified accordingly, e.g.: 

    o  The sender may generate a (small) subset of its RTP data packets
      with the ECN IP header field set to ECT(0) or ECT(1). 

"

"

[Qin]: are you saying slow initiation procedure may result in network
congestion?
In my understanding, when ECN-CE marked packet is received, the only
choice for sender
is to do congestion control since you are not sure if initiation
procedure lead to such
congestion. If it is not intiation procedure that lead to congestion,
you get risk to worse
congestion condition? 

[Thomas] I believe this does not only refer to initiation, but mainly to
feedback if congestion is encountered after the ECN media flow has been
established.

 

Regards!

-Qin

	----- Original Message ----- 

	From: Roni Even <mailto:[email-masked]>  

	To: [email-masked] 

	Hi,

	 

	Roni Even

	
________________________________

---

From: Qin Wu <[email-masked]>
Date: Wed, 12 Oct 2011 16:31:53 +0800

Hi,Thomas:
Your clarification make sense to me. Thanks.

Regards!
-Qin
  ----- Original Message ----- 
  From: Belling, Thomas (NSN - DE/Munich) 
  To: ext Qin Wu ; Roni Even ; [email-masked] 
  Cc: Magnus Westerlund 
  Sent: Tuesday, October 11, 2011 11:14 PM
  Subject: RE: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04

  Dear Qin, Magnus,

  Some replies to some of the earlier comments (I only briefly checked the rest).

  Thomas

  "

  "

   

  "

  "

  [Thomas] Negotiation is done with the 'ecn-capable-rtp' SDP attribute defined is this draft. Implantations not supporting ECN would ignore this, But this is independent of AVP or AVPF. 

  "

  "

  [Thomas] SDP capneg allows offering AVPF and AVP in the same media block, and also to relate SDP attributes to one of the transports only. Trouble is that this is not yet supported everywhere and has its problems with traversing intermediates not supporting it.

  [Qin]: It worth adding some text in the draft to make this clear.

  "

  "

   

  "

  "

  [Thomas] I believe this does not only refer to initiation, but mainly to feedback if congestion is encountered after the ECN media flow has been established.

   [Qin]: I think your interpretation is correct. But I am not sure this is a issue, no?. The prolem is do we have way to identify which factor lead to the final congestion.

  slow initiation, timely feedback or intermediary cheating in between.

  Regards!

  -Qin

    ----- Original Message ----- 

    From: Roni Even 

    To: [email-masked] 

    Hi,

     

    Roni Even

----------------------------------------------------------------------------

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Wed, 12 Oct 2011 07:57:16 -0500

Magnus, Roni - 

Congestion control is an important area, and I support this document moving forward  after we take care of some issues. 

In this note, I list a few important points, followed by some less important comments.

Important points -

For the multicast case, we need to make it clear that feedback goes to the feedback target, which may be a different device than the source. This document consistently says "feedback goes to the source", which is misleading. See the detailed comments below for the places in which I found it to be most concerning. When viewed in the context of feedback going to a discrete feedback target at the network egress edge (like typical IPTV deployments), it makes sense for the feedback target to use these reports as diagnostic in nature. Perhaps the network has changed topology and caused a bottleneck link to appear, and the feedback is triggering action in the network to fix the congestion in a systematic manner. It is highly unlikely that RTCP feedback will be able to change the rate of a flow in such a system. It is more likely that the system would take other actions, but that is probably beyond the scope of this document.

If a host is unable to read the ECN bits, it can't join an ECN-enabled flow? This seems to be quite onerous, and will likely slow down the adoption of ECN for RTP - particularly in the IPTV multicast case. If an operator needs to dual carry hundreds of video channels (one ECN marked and one not ECN marked), he will simply not implement ECN. I need to think about this a bit more and see if there is a way to make this work. My first instinct was to add a field/bit pattern to the RTCP feedback that says " I joined the ECN enabled flow, but can't actually read the ECT/ECN markings". However, let's think about naïve receivers that do not understand the ECN SDP. They will ignore that SDP line, and join the flow. They will provide their normal feedback, without the ECT/ECN portions. How is this different from a receiver that knows about ECN, but is unable to actually read the ECN bits? Maybe we just treat it like a legacy receiver that does not know about the ECN SDP....... So, we need to think about three receiver populations - fully ECN capable (as currently described in this document), ECN aware in the application but unable to read ECN bits (either acts like a legacy receiver or sends a special RTCP feedback message), ECN unaware (ignores the SDP). I have thought about this in the context of the declarative SDP case using leap of faith, but need to think more about the offer/answer case and the STUN case. We need a way to have each type of receiver unambiguously join the same multicast flow. This would allow an operator to incrementally deploy ECN on multicast flows. If we do not fix this, the operator will be gated on the very last device in his deployment.

It would be nice to have the RTCWEB folks take a courtesy look, as they are envisioning some very interesting use cases. I do not think that this presents any specific challenges, but it would be good to have those eyeballs. I see that at least a few of them have provided comments.........

A few minor points and a bit more specificity on the major points------------

There is a delicate balancing act between providing timely congestion notifications to the sender and sending feedback packets into a congested network. It is not clear that the this balancing act is discussed in enough detail in the document. An inexperienced implementer may "do the wrong thing" and send packets to freely, thus making the congestion worse. Perhaps a short paragraph in the introduction would make this clear? Perhaps a paragraph at the end of Page 11? Also in section 7.3.2, as congestion is not highly featured in RFC4585 or RFC3550. Congestion is mentioned in 7.3.2, as is feedback implosion, but there is no warning about how they can interact.

1---- Page 7

   ECN support is more important for RTP sessions than, for instance, is

   the case for TCP.

This is a quite bold statement. I suspect that the following sentence is closer to the truth, but it is truly a minor point.

ECN support is as important for RTP sessions as it is  for TCP.

2--- Page 13

---- begin rant ---- I am always troubled by language discussing  signaling protocols and discovery in RTP documents. We all know that declarative SDP is often used to configure endpoints. There is probably nothing that needs to be changed in this section, but I am noting that "declarative SDP" is not equal to a signaling protocol used for discovery. --- end rant ---

I need to think about the typical Service Provider use case- delivery of IPTV to a very large population of receivers. The system is setup with declarative SDP. Is the sender REALLY going to probe all of the receivers and stop marking packets with ECN if a few receivers don't respond? If you have a population of several million receivers at the end of DSL lines, what are the odds of none of them being offline for a few minutes? I would venture a guess that it is pretty small. In this case, the "leap of faith" is probably what the network operator will do....... So, I do not think I have a problem with this section, other than the rant.

3--- Page 13

Considering again the case of the large Service Provider. The feedback target for the flow is usually a repair device rather than the sender. It is not clear from the text if the RTCP is going to the repair device or the sender. 

4--- Page 14

Is feedback send to the sender, or to the feedback target? Hopefully it goes to the feedback target, or else you are going to have one hell of a feedback storm in certain deployments.

5--- Page 15

I need to think about the case in which a large IPTV deployment is using these methods, then one of the subscribers deploys a wireless gateway that mangles ECT/ECN packets. It is not clear that the sender SHOULD stop sending ECT/ECN marked packets. In a perfect world, the subscriber would have a way to know that the problem is in the gateway..... I am not sure we can fix this problem in the scope of this document, though.

6--- Page 15, and then sprinkled throughout the document

Is feedback send to the sender, or to the feedback target?

7--- My SDP skills are suspect. It looked OK on a quick read, but hopefully somebody is looking at this in detail. I am not sure I like the setread/setonly/readonly semantics, but I do not have a counter-proposal.

8--- Page 23 and 24

If a host is unable to read the ECN bits, it can't join an ECN-enabled flow? This seems to be quite onerous, and will likely slow down the adoption of ECN for RTP. This is particularly true of the "large IPTV deployment" that wants to send multicast flows to STB, PC, Xbox, tablet, etc. If there are millions of receivers, that means that there are dozens/hundreds/thousands of device types. If the operator is gated on having ECN support on all of the devices, this will never get deployed. Perhaps we can change the feedback report to say " I joined the stream, but can't actually read the ECN bits, so do not count me in your ECN algorithm".

9--- section 7.2.1

If the feedback goes to a discrete feedback target, the system will have to correlate the responses and send a summary to the original sender.

10 --- page 28

change

For video formats, packets containing P- or B-frames, rather than I-frames,

      would be an appropriate choice

to

For video formats, packets containing NULLS, P-frames or B-frames (rather than I-frames),

      would be an appropriate choice

11--- page 29

For streams with millions of receivers (think IPTV and the World Cup Final), the group will never be stable for three RTCP reporting intervals. Perhaps a group associated with a given feedback target would be stable for this long, but even that is marginal.

BVS

From: [email-masked] [mailto:[email-masked]] On Behalf Of Roni Even
Sent: Friday, September 30, 2011 8:29 AM
To: [email-masked]
Subject: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04

Hi,

I would like to start a WGLC on http://tools.ietf.org/html/draft-ietf-avtcore-ecn-for-rtp-04 , Explicit Congestion Notification (ECN) for RTP over UDP.

 

Roni Even

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 13 Oct 2011 10:35:05 -0700

Two comments:

1. The section
http://tools.ietf.org/html/draft-ietf-avtcore-ecn-for-rtp-04#section-7.2.2
does not seem to discuss what happens if the ECN-marked ICE messages are
discarded (e.g., by an aggressive firewall).  This seems to be an oversight.
For this to work better, I suggest sending two STUN messages, back to back:
one with ECN set and the other with ECN clear.  If the response to the
ECN-set message isn't received within, say, 20% of the time for the
ECN-cleared message, assume ECN-marked messages are being dropped/filtered.
Note one of the non-ECN'd messages can be the normal ICE exchange, so if
you're already doing ICE I am not proposing any additional messages on the
wire.

I expect the other packet probes (RTP/RTCP probes) may need similar
consideration / adjustment.

2. The section
http://tools.ietf.org/html/draft-ietf-avtcore-ecn-for-rtp-04#section-7.2.2
can be summarized as:

  a. do normal ICE
  b. use ICE messages to do an ECN validation
  c. if (b) showed ECN worked, start sending RTP with ECN.  
  d. if (b) showed ECN failed, start sending RTP without ECN.

Step (b-d) adds additional call setup time, which is undesirable.

Instead, I would prefer changing two aspects:  (1) not relying or caring
about an initial ICE transaction (which means we can have both endpoints
merely do ICE-Lite, if they wish -- we only need to know they will respond
to ICE, really -- we don't need all of the other ICE overhead to use ICE to
test the path is ECN capable), and (2) sending non-ECN'd RTP without
waiting.  That can be summarized as:

  a. immediately start sending RTP without ECN
  b. use ICE messages to do ECN validation
  c. if (b) showed ECN worked, start sending RTP with ECN.  
  d. if (b) showed ECN failed, start sending RTP without ECN.

-d

> -----Original Message-----
> Sent: Friday, September 30, 2011 5:29 AM
> To: [email-masked]
> I would like to start a WGLC on http://tools.ietf.org/html/draft-ietf-
> avtcore-ecn-for-rtp-04 , Explicit Congestion Notification (ECN) for RTP
> over UDP.
> 
>

---

From: "Piers O'Hanlon" <[email-masked]>
Date: Fri, 14 Oct 2011 15:54:44 +0100

Dear Qin,

Thanks for your feedback. Comments inline [omitting Thomas's clarifications]

> the first word in this sentence with "these transport"?
The 'these' in the second sentance refers to the transport protocols
(not ECN). I think the existing wording is probably ok.

> to change it as these transport protocols header
This paragraph is aiming to describe the existing ECN enabled transport
protocols so it does not refer to RTCP/AVPF messages.  We have
attempted to describe
the feedback process in a generic way as they all have their own way of feeding
back the ECN state information - so there is inevitably some lack of
specificity.

> [Qin]: Any requirements that should be met by the middlebox or intermediate
These are just a list of requirements on the protocol - and
correspondingly on any equipment that implements this protocol (which
could include a middlebox, intermediate node, MCU, router etc).
So such support is implied for any of these boxes.

> rephrased as "This is for a standard unicast flow".
This may benefit from some rewording.

> [Qin]: Five is default value of the timeout multiplier, do you think other
That issue is down to compliance with the RTP spec:
http://tools.ietf.org/html/rfc3550#section-6.3.5
Where 5 is specified as the default value, so in principle it's
possible to choose something else but that could lead to problems.

> [Qin]: Is "shout if you want ECN" appropirate language here?
Well it serves the purpose - given that this not a recommended topology and
is shall not be used with ECN.

> [Qin]: Should "rate" in this sentence be data rate or bitrate?
It is intentionally left open as one could alter the bit/byte rate or
the packet rate.

>        Are you saying RFC3551 following Regular RTCP timing rule?
Yes - That sentence is just reiterating the RFC3551 timing rules so
that the read may understand the limitations of using that approach
(as opposed to employing AVPF).

>    I am wondering can we say ECN with RTP can be used with the standard RTP/
We have explicitly mentioned that it is possible to use RFC3551 but
performance may be limited. RFC3551 doesn't have any impact upon the
SDP negotiations.

>  into the same media block? I don't really understand the rationale. Would
> you like to clarify a little bit?
>
This list is meant to describe the overall pieces of the solution -
not necessarily every single step.

> [Qin]: Would it be better to add an anchor pointing to the section 6.1.1 and
I'm not sure if that is necessary.

> [Qin] Would it better to put reference to the section 6 of RFC4566 for
Since it is independent of the character set it is probably necessary
to add the reference.

> ECT(1) is chosen. I think it should be clear in the text.
As you explain that is what is meant in the paragraph. It seems fairly
clear as we have put
it - Though the mapping between "0" and ECT(0) is not explicitly
mentioned till the end so we
may need to address this.

> paragraph is not correct.
This is correct - it just another way of saying this the default value
but the current wording makes sense

> [Qin]: Should "used" in this sentence be "use"?
Yes that needs changing.

>  [Qin]: Should "requiring" in this sentence be "requires"?
Yes that sentence may need some modification.

> [Qin]: Should "first packets" be "first packet" and "IP packets" be "IP
No - as there are more than of these packets.

> [Qin]: s/the receivers/receiver
I'm not sure that is necessary.

>  tell the sender ECN is not used.
As mentioned earlier in the section the "behaviours" will be detected by the
end-systems. The 'one' is the parties involved in the connection setup - which
could in certain cases be a 'middlebox' - but that doesn't need to be explicitly
covered here.

>  damaging affect on others.
I think you're correct there.

>         what you said about "The above optimization supports peer to peer
In the case of multicast the optimisation wouldn't apply.

> optimization can not apply.
For the first part you are correct, but the the two stream case only
talks about a
'logical endpoint' i.e. a single RTP endpoint which is split over
multiple hosts, not
separate RTP endpoints.

> [Qin]: What's the media impact? It looks like a new term that needs to be
> explained somewhere.
>
It refers to the effect of the ECN path discovery mechanisms that need to be
normally employed at session initiation. We could explain this a little better.

> [Qin]: Is the sender in this sentence "the media sender" or new participant?
The sender would be the entity that sent the STUN message in the first place.

>  or other participants? It should be clear in the text.
The other senders are the other existing participants (i.e. Not the
new participant).

>  Suggest to remove ", and detecting failures and misbehaving receivers" from
Agreed.

> [Qin]: Is it true, since RTP/AVPF Transport Layer ECN Feedback packet
> include the satistics of ECT marks?
>
Yes - whilst the RTCP packet may contain information regarding the ECN markings,
they are not themselves ECT marked.

> [Qin]: Should "then" in this sentence be "than" ?
No.

> [Qin]: What and where are the figures?
The 'figures' refers to the values of the various counters of ECN markings, as
explained earlier in the paragraph.

> can you explain a little bit?
Because the translator actually alters the packet stream there is not always
a clear mapping between the values taken from the original packets vs the
translated packets. But if a particular event has been reported it is best to
report that event (e.g. ECN-CE marking) has occurred in the translated
packets - but they may not always add up correctly if one wants to indicate
that a marking is now 'spread' over more than one packet in the translated
stream. The rounding used means that it shouldn't round down to zero unless
the pre-translated values are zero.

>  between media sender and mixer? are you saying congestion control loop is
This may needs clarifying a little, though basically the 'control
loop' refers to the
overall exchange of messages - which are then used to drive 'congestion control
loop'. The congestion control loop is not unidirectional.

> [Qin]: Why discrepacies is allowed? Should these example be consistent with
This a good point - we will take a look at them.

> report are allowed and configured or something else?
Yes that probably needs a small clarification. We're basically saying
that they're
both supported - though not necessarily configured as yet,

Thanks,

Piers.

---

From: Qin Wu <[email-masked]>
Date: Tue, 18 Oct 2011 14:14:18 +0800

Hi,Piers:
You address most of my comments which are removed from this followup.
Please see a few my remaining comments below.

Regards!
-Qin
----- Original Message ----- 
From: "Piers O'Hanlon" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: "Roni Even" <[email-masked]>; <[email-masked]>; "Magnus Westerlund" <[email-masked]>
Sent: Friday, October 14, 2011 10:54 PM
Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04

Dear Qin,

[Qin]: I know. But the problem is you change the subject in two consecutive sentences which looks ambiguity to me.
that's why I suggest you to do some rewording.

[Qin]: It looks not clear to me at the first glance since I misunderstood "the Feedback" as "RTCP Feedback message".
But I am okay with your clarification.

[Qin]: It is still not clear to me.If end system detects those behavior and one is the middlebox, 
how end systems that detects those behavior tellsthe middlebox that those behaviro occur, 
through dedicated ECN feedback message or any other means? or you assume the middlebox 
can be a receiver?

[Qin]: In this case, CNAME is not enough to identify each of RTPendpoints.
>From this perspective, I agree.
Is that what you are saying? 

No.

[Qin]: Why? Using "different from" instead?

[Qin]: I misunderstood "figures" as "charts" or "drawings", Isn't worth better wording?

[Qin]: Thank for your clarfication, I am clear, it is better to replace
"
The translator should also try to ensure that no non-zero counter is
 rounded to a zero value
"
with your proposed text
"
The translator should also try to ensure that no non-zero counter is
 rounded to a zero value  unless the pre-translated values are zero.
"
That will be more clear to me.

Thanks,

Piers.

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 19 Oct 2011 16:18:01 +0200

Hi,

Thanks for the comments.

> consideration / adjustment.

Yes, you are correct that we don't have a specification for when the ICE
client should consider the ECN check as being failed. I think we should
allow the ICE agent to send multiple transmissions of the ECN STUN check
packets. The second aspect is that I think 20% extra delay is to little.
The STUN packet may easily suffer that amount of network jitter.

My proposal would be to add the following paragraph to Section 7.2.2:

The ECN STUN checks may be lost on the path, either due to the ECT
marking in the ECN field or for some other reason. The first will result
in a failure to verify the path as ECT. The second should not result in
a failure to verify the path. Therefore a number of retransmissions
should be attempted. But, the sender of ECN STUN checks will also have
to set a criteria for when it gives up testing for ECN capability on the
path. As the ICE agent have successfully verified the path a RTT
measurement for this path can be performed. To have high probability of
succesfully verifying the path it is RECOMMENDED that the client
retransmitt the ECN STUN check 5 times. The interval between the
retransmissions will be based on the Ta timer as defined in Section 16.1
for RTP Media Streams in ICE [RFC5245]. The number of ECN STUN checks
needing to be sent will depend on the number of ECN capable flows (N)
that is to be established. Thus the interval between each transmission
of an ECN check packet MUST be Ta. In other words for a given flow being
verified for ECT the RTO is set to Ta*N. The transmission for that flow
is stopped when an ECN Check STUN response has been received which don't
indicate to retransmit the request due to temporary error. The ICE agent
is recommended to give up on the ECN verification MAX(1.5*RTT, 20 ms)
after the last ECN STUN check was sent.

When it comes to RTP I think we have a clear criteria for failure in 7.2.1:

ECN initiation is considered to have failed at the instant when any RTP
session participant sends an RTCP packet that doesn't contain an RTCP
ECN feedback report or ECN summary report, but has an RTCP RR with an
extended RTP sequence number field that indicates that it should have
received multiple (>3) ECT marked RTP packets. This can be due to
failure to support the ECN feedback format by the receiver or some
middlebox, or the loss of all ECT marked packets. Both indicate a lack
of ECN support.

>   d. if (b) showed ECN failed, start sending RTP without ECN.

I disagree with the disconnection from ICE processing. First of all the
side that want to determine if the path from it to the other side must
be an ICE node. The other side could be an ICE-Lite supporting the ECN
check attribute. But if the goal is to establish if the path is ECT
bi-directionally then both sides need to be ICE capable.

Secondly, I think the optimization you propose is good and I think we
can accept it with the note that I would like much more conservative ECN
STUN check transmission schedule if we are going to do media in parallel.

However, this is an substantiative change so I would like to see if
there is WG support for it.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 19 Oct 2011 16:41:08 +0200

Bill,

Thanks for the review. I here respond to the major issues. If needed I
will follow up on the minor issues, otherwise I will simply implement
them in the next update.

On 2011-10-12 14:57, Bill Ver Steeg (versteb) wrote:
> 
> For the multicast case, we need to make it clear that feedback goes to
> the feedback target, which may be a different device than the source.
> This document consistently says “feedback goes to the source”, which is
> misleading. See the detailed comments below for the places in which I
> found it to be most concerning. When viewed in the context of feedback
> going to a discrete feedback target at the network egress edge (like
> typical IPTV deployments), it makes sense for the feedback target to use
> these reports as diagnostic in nature. Perhaps the network has changed
> topology and caused a bottleneck link to appear, and the feedback is
> triggering action in the network to fix the congestion in a systematic
> manner. It is highly unlikely that RTCP feedback will be able to change
> the rate of a flow in such a system. It is more likely that the system
> would take other actions, but that is probably beyond the scope of this
> document.

I think we might not have been sufficient clear on the SSM case. But in
fact for this to work, the Feedback Targets will need to relay the
feedback, at least in aggregated form to the source (or at least the
entity marking the packets as ECN which might be the Distributuion
Source).

> 
>  
> 
> If a host is unable to read the ECN bits, it can’t join an ECN-enabled
> flow? This seems to be quite onerous, and will likely slow down the
> adoption of ECN for RTP – particularly in the IPTV multicast case. If an
> operator needs to dual carry hundreds of video channels (one ECN marked
> and one not ECN marked), he will simply not implement ECN. I need to
> think about this a bit more and see if there is a way to make this work.
> My first instinct was to add a field/bit pattern to the RTCP feedback
> that says “ I joined the ECN enabled flow, but can’t actually read the
> ECT/ECN markings”. However, let’s think about naïve receivers that do
> not understand the ECN SDP. They will ignore that SDP line, and join the
> flow. They will provide their normal feedback, without the ECT/ECN
> portions. How is this different from a receiver that knows about ECN,
> but is unable to actually read the ECN bits? Maybe we just treat it like
> a legacy receiver that does not know about the ECN SDP....... So, we
> need to think about three receiver populations – fully ECN capable (as
> currently described in this document), ECN aware in the application but
> unable to read ECN bits (either acts like a legacy receiver or sends a
> special RTCP feedback message), ECN unaware (ignores the SDP). I have
> thought about this in the context of the declarative SDP case using leap
> of faith, but need to think more about the offer/answer case and the
> STUN case. We need a way to have each type of receiver unambiguously
> join the same multicast flow. This would allow an operator to
> incrementally deploy ECN on multicast flows. If we do not fix this, the
> operator will be gated on the very last device in his deployment.
> 

Lets start with commenting on the naive receivers, if they join an ECN
enabled RTP session they will cause the session to stop using ECN. That
is why we say the same to a receiver that knows about ECN but can't read
the session. If they join they will force the session into not-ECT
operations.

Yes, this is onerous. But we can't frankly figure out how we can allow
any other behavior in any best-effort network. Having receivers get
preferential treatment of their traffic compared to not-ECT marked in a
best effort seems problematic if they aren't reporting back on it and
telling the sender to adjust the bit-rate.

We know from that start that ECN and large scale multicast would be
problematic and that is not our main target. This as it will be
difficult to combine source rate modifications with large groups.

I think we authors are still of the opinion that we develop what is safe
but possibly overly conservative and get that published. If people want
to improve the ECN in multicast usage later they are free to do so. But
tackling the issues that arise from letting non ECN capable receivers
into a group that uses ECN is problematic. So my opinion is that we
shouldn't change anything in this behavior.

> 
> It would be nice to have the RTCWEB folks take a courtesy look, as they
> are envisioning some very interesting use cases. I do not think that
> this presents any specific challenges, but it would be good to have
> those eyeballs. I see that at least a few of them have provided comments………
> 

Which RTCWEB folks do you want to have a look at this?

My personal view that I would love to have overturned is that ECN in
open Internet is so dysfunctional that it is barely worth trying. Thus
adding ECN support to RTCWEB nodes in the initial phase is lots of work
for the implementor with very little bang back.

> There is a delicate balancing act between providing timely congestion
> notifications to the sender and sending feedback packets into a
> congested network. It is not clear that the this balancing act is
> discussed in enough detail in the document. An inexperienced implementer
> may “do the wrong thing” and send packets to freely, thus making the
> congestion worse. Perhaps a short paragraph in the introduction would
> make this clear? Perhaps a paragraph at the end of Page 11? Also in
> section 7.3.2, as congestion is not highly featured in RFC4585 or
> RFC3550. Congestion is mentioned in 7.3.2, as is feedback implosion, but
> there is no warning about how they can interact.

I think we can add more warnings and check that we are clear on that one
must follow the transmission rules for the session the end-point is
operating. I would note that congestion is in fact likely asymmetric.
Thus just because you receive CE marked packets doesn't mean that the
RTCP FB packets will go over path that is loaded into congestion and of
course the reverse.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 19 Oct 2011 17:48:06 +0200

Hi,

some more in detail comments.

I propose that the SSM usage is clarified in section 3.3 by adding the
following text.

      SSM groups that uses unicast RTCP feedback [RFC5760] do need a few
      extra considerations.  This topology can have multiple media
      senders that provides traffic to the distribution source (DS) and
      are separated from the DS.  There can also be multiple feedback
      targets.  The requirement for using ECN for RTP in this topology
      is that the media sender must be provided the feedback from the
      receivers, it may be in aggregated form  from the feedback
      targets.  We will not mention this SSM use case in the below text
      specifically, but when actions are required by the media source,
      they do apply also to case of SSM where the RTCP feedback goes to
      the Feedback Target.

But, I guess that you might find this insufficient. But, I don't see how
we can take care of all implications of large scale multicast usage.

Maybe what we should add is:

"This specification do support multicast, but has primarily considered
smaller multicast groups and is not optimized for larger groups and
their needs."

On 2011-10-12 14:57, Bill Ver Steeg (versteb) wrote:
> This is a quite bold statement. I suspect that the following sentence is
> closer to the truth, but it is truly a minor point.
> 

I still believe based on the motivation provided below this sentence
that the original one is true. Yes, I can see if "delay" is your main
performance factor, then TCP might be similarly benefited by ECN.

> 
> 2--- Page 13
> 
> ---- begin rant ---- I am always troubled by language discussing 
> signaling protocols and discovery in RTP documents. We all know that
> declarative SDP is often used to configure endpoints. There is probably
> nothing that needs to be changed in this section, but I am noting that
> “declarative SDP” is not equal to a signaling protocol used for
> discovery. --- end rant ---
> 
> I need to think about the typical Service Provider use case- delivery of
> IPTV to a very large population of receivers. The system is setup with
> declarative SDP. Is the sender REALLY going to probe all of the
> receivers and stop marking packets with ECN if a few receivers don’t
> respond? If you have a population of several million receivers at the
> end of DSL lines, what are the odds of none of them being offline for a
> few minutes? I would venture a guess that it is pretty small. In this
> case, the “leap of faith” is probably what the network operator will
> do……. So, I do not think I have a problem with this section, other than
> the rant.

I assume the rant is over this following sentence:

   Before an RTP session can be created, a signalling protocol is used
   to discover the other participants and negotiate or configure session
   parameters (see Section 7.1).

Is this better?

   Before an RTP session can be created, a signalling protocol is used
   to negotiate or at least configure session parameters (see
   Section 7.1).  In some topologies the signalling protocol can also be
   used to discover the other participants.

> 
> 3--- Page 13
> 
> Considering again the case of the large Service Provider. The feedback
> target for the flow is usually a repair device rather than the sender.
> It is not clear from the text if the RTCP is going to the repair device
> or the sender.

I assume this is sentence that triggers your comment:

 Upon reception of this feedback from each
      receiver it knows of, the sender can consider ECN functional for
      its traffic.

Is that more acceptable in the light of the section 3.3 addition making
clear the requirement that in case of SSM the media sender will get a
aggregated information.

> 
> 4--- Page 14
> 
> Is feedback send to the sender, or to the feedback target? Hopefully it
> goes to the feedback target, or else you are going to have one hell of a
> feedback storm in certain deployments.

Well, if you have an SSM with feedback targets then it goes to the
feedback targets. As stated in 3.3 addition I see an feedback target
aggregating the information to the media sender.

> 
> 5--- Page 15
> 
> I need to think about the case in which a large IPTV deployment is using
> these methods, then one of the subscribers deploys a wireless gateway
> that mangles ECT/ECN packets. It is not clear that the sender SHOULD
> stop sending ECT/ECN marked packets. In a perfect world, the subscriber
> would have a way to know that the problem is in the gateway….. I am not
> sure we can fix this problem in the scope of this document, though.

No, I don't see how we really can deal with it. As I said before I think
we likley need that disclaimer for larger multicast groups.

> Is feedback send to the sender, or to the feedback target?

It is sent to where ever you send your RTCP packets, but the feedback is
addressed to the SSRC that you report on.

> 
> 7--- My SDP skills are suspect. It looked OK on a quick read, but
> hopefully somebody is looking at this in detail. I am not sure I like
> the setread/setonly/readonly semantics, but I do not have a
> counter-proposal.

Noted, input by SDP gurus desired.

> adoption of ECN for RTP. This is particularly true of the “large IPTV
> deployment” that wants to send multicast flows to STB, PC, Xbox, tablet,
> etc. If there are millions of receivers, that means that there are
> dozens/hundreds/thousands of device types. If the operator is gated on
> having ECN support on all of the devices, this will never get deployed.
> Perhaps we can change the feedback report to say “ I joined the stream,
> but can’t actually read the ECN bits, so do not count me in your ECN
> algorithm”.

Yes, but as stated in previous email I don't see how we can allow
someone who don't react, nor report to the congestion signals to join
the group.

> 
> 9--- section 7.2.1
> 
> If the feedback goes to a discrete feedback target, the system will have
> to correlate the responses and send a summary to the original sender.

Yes, I think this would be fixed by 3.3 addition.

>       would be an appropriate choice

I have done the change, but isn't this a US vs UK english thing?

> 
> 11--- page 29
> 
> For streams with millions of receivers (think IPTV and the World Cup
> Final), the group will never be stable for three RTCP reporting
> intervals. Perhaps a group associated with a given feedback target would
> be stable for this long, but even that is marginal.

I agree this is an issue. But I would group this with the large
multicast group issues that we have identified as being problematic.

Cheers

Magnus Westerlund

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 19 Oct 2011 09:25:18 -0700

...
> there is WG support for it.

With the years-long bru-hah-hah of ICE being misunderstood for "delaying
call set up", it seems important for the success of ECN RTP to ensure
it does not suffer that same fate.  That would delay/prevent ECN RTP's
widespread deployment.

-d

---

From: "Piers O'Hanlon" <[email-masked]>
Date: Thu, 20 Oct 2011 13:33:52 +0100

Hi Qin

Comments inline.

> that's why I suggest you to do some rewording.
I can understand your concern but I think it is clear enough as is.

> through dedicated ECN feedback message or any other means? or you assume the middlebox
The term "middlebox" is rather generic and can apply to wide range of
entities including
ones that implement ECN for RTP (e.g. RTP mixer/translators). These
entities would be
able to detect bad behaviours and react to them according to this
document's specification.
However other middleboxes that don't actually take part in the session
may also be able detect
what they see as bad behaviour but their operation is out of scope of
this document.

> multiple hosts, not separate RTP endpoints.
>
Yes.

> [Qin]: Why? Using "different from" instead?
I'm sorry you're correct here (I initially looked at the wrong 'then').

> [Qin]: I misunderstood "figures" as "charts" or "drawings", Isn't worth better wording?
I can understand that one may confuse the meaning but I think it ok as is.

> That will be more clear to me.
We could add that clarification.

Thanks again,

Piers.

---

From: Qin Wu <[email-masked]>
Date: Thu, 20 Oct 2011 13:21:12 +0000

Hi,Piers:
You address my comments, thanks!

Regards!
-Qin
____________________________________
发件人: [email-masked] [[email-masked]] 代表 Piers O'Hanlon [[email-masked]]
发送时间: 2011年10月20日 20:33
到: Qin Wu
Cc: Magnus Westerlund; [email-masked]
主题: Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04

Hi Qin

Comments inline.

Yes.

Thanks again,

Piers.

---

From: Roni Even <[email-masked]>
Date: Sat, 22 Oct 2011 01:40:14 +0200

Hi,

I am slow on my review and looked only at part of the comments so far so I
may repeat them.

1.       In section 6.1.1 when talking about multicast and ecn it is not
clear what should be the policy for the init value, can each receiver select
different one or must the offer only include one init value similar to the
declarative case

2.       In section 6.1.3 "If timely feedback is not required it is still
RECOMMENDED  to used RTP/AVPF." If AVP is used how will you signal the
ecn-ce since it is done with an AVPF rtcp message which is not supported in
AVP or in this case only the XR message will be used?

Nit: In section 5.2 " Report and is  be based ."  delete the "be"

Roni Even

As individual

From: [email-masked] [mailto:[email-masked]] On Behalf Of Roni
Even
Sent: Friday, September 30, 2011 3:29 PM
To: [email-masked]
Subject: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04

Hi,

 

Roni Even

  _____

---

From: Roni Even <[email-masked]>
Date: Sat, 22 Oct 2011 14:05:20 +0200

Hi,

I finished the review.

1.      In section 7.2  "All session participants connected over the same
transport   will need to use the same initiation method. " maybe say MUST
use instead of will need to use.

2.       In section 7.2 " If support for both in-band and out-of-band
mechanisms is signalled, the sender SHOULD try ECN negotiation using  STUN
with ICE first, and if it fails, fallback to negotiation using  RTP and RTCP
ECN feedback" I think that it should say that the sender should offer ice
initialization method before rtp.

3.       In section 7.2.1 you reference the no-op draft. Why not reference
the keep-alive RFC

4.       In section 7.2.1 Generating RTCP ECN Feedback it says "Reception of
subsequent ECN-CE marked packets MUST  result in additional early or
immediate ECN". Why use MUST and not SHOULD since there is an exception case
following the sentence.

5.       In section 7.2.1 "ECN initiation is considered to have failed at
the instant when any RTP session participant sends an RTCP packet that
doesn't  contain an RTCP ECN feedback report or ECN summary report " The
RTCP ECN feedback report may be missing for other reasons like no timely
response or using AVP profile.

6.       In section 7.3.3 receiver driven congestion control you mention
layered codecs as an option I think that using ccm tmbbr is more useful when
there are no layered codecs in use (more common today) and should be
mentioned in this section.

7.       In section 10.6 you use the wrong range definition "From RFC 5389:
STUN Attribute types in the first half of the comprehension-required range
(0x0000 - 0x3FFF) and in the first half of the comprehension- optional range
(0x8000 - 0xBFFF) are assigned by IETF Review"

Roni Even

As individual

 

Hi,

 

Roni Even

  _____

---

From: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 24 Oct 2011 12:21:38 +0200

Hi Ron,

in my understanding with AVP only XR would indeed be used.

(In addition, for the AMR and AMR/WB codec you have "mode requests"
within the AMR RTP payload for a payload specific adjustment. This also
works with AVP.)

Thomas

From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext Roni Even
Sent: Saturday, October 22, 2011 1:40 AM
To: [email-masked]
Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04

Hi,

I am slow on my review and looked only at part of the comments so far so
I may repeat them.

1.       In section 6.1.1 when talking about multicast and ecn it is not
clear what should be the policy for the init value, can each receiver
select different one or must the offer only include one init value
similar to the declarative case< lass=MsoListParagraph
style='text-indent:-.25in;mso-list:l0 level1 lfo1'>In section 6.1.3 "If
timely feedback is not required it is still RECOMMENDED  to used
RTP/AVPF." If AVP is used how will you signal the ecn-ce since it is
done with an AVPF rtcp message which is not supported in AVP or in this
case only the XR message will be used?

Nit: In section 5.2 " ..."  delete the "be"

Roni Even

As individual

Fr om:

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 27 Oct 2011 15:35:56 +0200

Hi Roni,

Thanks for the feedback.

On 2011-10-22 14:05, Roni Even wrote:
> 
> 1.      In section 7.2  "All session participants connected over the
> same transport   will need to use the same initiation method." maybe say
> MUST use instead of will need to use.

sure.

> mechanisms is signalled, the sender SHOULD try ECN negotiation using 
> STUN with ICE first, and if it fails, fallback to negotiation using  RTP
> and RTCP ECN feedback" I think that it should say that the sender should
> offer ice initialization method before rtp.

I would suggest to formulate this as:

If support for both in-band and out-of-band mechanisms are signalled,
the sender when negotiating SHOULD offer detection of ECT using STUN
with ICE with higher priority than detection of ECT using RTP and RTCP.

> 
> 3.       In section 7.2.1 y ou refer not reference the keep-alive RFC

Why do you think we should reference RFC 6263? Is is because we discuss
which packets would have least impact on the media flow when used as ECT
probes? IF that is the reasons I don't think RFC6263 has much to offer.
The outcome of this document is that nothing short of real RTP or RTCP
packets work well for keep-alive. And in this context of ECN we can't
use the RTCP packets.

> 
> 4.       In section 7.2.1 Generating RTCP ECN Feedback it says
> "Reception of subsequent ECN-CE marked packets MUST  result in
> additional early or immediate ECN". Why use MUST and not SHOULD since
> there is an exception case following the sentence.

Because if we use SHOULD then one might consider that additional
exceptions than just that one exists. And that is not the case. If you
use a method that requires timely feedback, then you better send that
feedback.

> 
> 5.       In section 7.2.1 "ECN initiation is considered to have failed
> at the instant when a ny RTP s an RTCP packet that doesn't  contain an
> RTCP ECN feedback report or ECN summary report " The RTCP ECN feedback
> report may be missing for other reasons like no timely response or using
> AVP profile.

I think you are misunderstanding what was written, maybe because of the
bad formulation in the sentence. I have rewritten this to:

ECN initiation is considered to have failed at the instant the
initiating RTP sender received an RTCP packet that doesn't contain an
RTCP ECN feedback report or ECN summary report from any RTP session
participant that has an RTCP RR with an extended RTP sequence number
field that indicates that it should have received multiple (>3) ECT
marked RTP packets.

Is that clearer?

> layered codecs as an option I think that using ccm tmbbr is more useful
> when there are no layered codecs in use (more common today) and should
> be mentioned in this section.

I am very split about discussing this. I know there exist
implementations that uses TMMBR as primary congestion control. However,
RFC 5104 hasn't specified it in that way.

I also see an issue with bringing it up in this context, namely that we
bless this without any specification or requirements on the solution.
For example how responsive to congestion is the usage of TMMBR. One
parameter is the  AVPF operations mode and due to this RTCP bandwidths.
another is the algorithm determining the appropriate bit-rate.

I know that the multicast scalable encoding share similar concerns but
there we have even less alternatives.

I think reformulating the introduction of the section to make clear that
this is just an example of Receiver driven congestion control is most
appropriate.

In a receiver driven congestion control mechanism, the receivers can
react to the ECN-CE marks themselves without providing ECN-CE feedback
to the sender. This may allow faster response than sender-driven
congestion control in some circumstances and also scale to large number
of receivers and multicast usage. One example of receiver-driven
congestion control is implemented by providing the content in a layered
way, with each layer providing improved media quality but also increased
bandwidth usage.

> 
> 7.&nbs ;  In section 10.6 you use the wrong range definition "From RFC
> 5389: STUN Attribute types in the first half of the
> comprehension-requiredrange (0x0000 - 0x3FFF) and in the first half of
> the comprehension- optional range (0x8000 - 0xBFFF) are assigned by IETF
> Review"
> 

Good catch.

Thanks

Magnus Westerlund

---

From: Roni Even <[email-masked]>
Date: Thu, 27 Oct 2011 15:53:14 +0200

Magnus,
I am OK with your answers
Roni

> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Thursday, October 27, 2011 3:36 PM
> To: Roni Even
> Cc: [email-masked]
> Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04 - more
> 
> Hi Roni,
> 
> Thanks for the feedback.
> 
>