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

Qin Wu <> Tue, 11 October 2011 02:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D7DF921F8C6F for <>; Mon, 10 Oct 2011 19:49:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.388
X-Spam-Status: No, score=-3.388 tagged_above=-999 required=5 tests=[AWL=-0.573, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_84=0.6, MANGLED_LIST=2.3, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DEbPfKVYDrB8 for <>; Mon, 10 Oct 2011 19:49:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E513821F8C6E for <>; Mon, 10 Oct 2011 19:49:55 -0700 (PDT)
Received: from (szxga04-in []) by (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <> for; Tue, 11 Oct 2011 10:46:32 +0800 (CST)
Received: from ([]) by (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <> for; Tue, 11 Oct 2011 10:46:32 +0800 (CST)
Received: from ([]) by (MOS 4.1.9-GA) with ESMTP id AED86479; Tue, 11 Oct 2011 10:46:29 +0800
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Tue, 11 Oct 2011 10:46:26 +0800
Received: from w53375q ( by ( with Microsoft SMTP Server (TLS) id; Tue, 11 Oct 2011 10:46:20 +0800
Date: Tue, 11 Oct 2011 10:46:19 +0800
From: Qin Wu <>
X-Originating-IP: []
To: Roni Even <>,
Message-id: <>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
Content-type: multipart/alternative; boundary="Boundary_(ID_ylaBF/OsDDeImGWJZ5qkeg)"
X-Priority: 3
X-MSMail-priority: Normal
X-CFilter-Loop: Reflected
References: <016101cc7f6c$9795e380$c6c1aa80$>
Cc: Magnus Westerlund <>
Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 Oct 2011 02:49:59 -0000

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 

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
[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?


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


I would like to start a WGLC on , 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




  Audio/Video Transport Core Maintenance