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

Dear Qin,

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

On 11 October 2011 03:46, Qin Wu <bill.wu@huawei.com> wrote:
> 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"?
>
The 'these' in the second sentance refers to the transport protocols
(not ECN). I think the existing wording is probably ok.

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

> 4. Section 3.1
>
> [Qin]: Any requirements that should be met by the middlebox or intermediate
> node?
>
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.

>
> 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".
>
This may benefit from some rewording.

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

> "
> 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?
>
Well it serves the purpose - given that this not a recommended topology and
is shall not be used with ECN.

>
> 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?
>
It is intentionally left open as one could alter the bit/byte rate or
the packet rate.

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

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

> 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?
>
This list is meant to describe the overall pieces of the solution -
not necessarily every single step.

> 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?
>
I'm not sure if that is necessary.

> 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?
>
Since it is independent of the character set it is probably necessary
to add the reference.

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

> Also I think the text like ""0" being implied if not specified" in this
> paragraph is not correct.
>
This is correct - it just another way of saying this the default value
but the current wording makes sense

> 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"?
>
Yes that needs changing.

> 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"?
>
Yes that sentence may need some modification.

> 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"?
>
No - as there are more than of these packets.

> "
> If the path between the sender and the receivers exhibits either of these
> behaviours one
> "
> [Qin]: s/the receivers/receiver
>
I'm not sure that is necessary.

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

> 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
>
I think you're correct there.

> "
> 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?
> "
In the case of multicast the optimisation wouldn't apply.

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

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

> 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?
>
The sender would be the entity that sent the STUN message in the first place.

> 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.
>
The other senders are the other existing participants (i.e. Not the
new participant).

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

> 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?
>
Yes - whilst the RTCP packet may contain information regarding the ECN markings,
they are not themselves ECT marked.

> 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" ?
>
No.

> 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?
>
The 'figures' refers to the values of the various counters of ECN markings, as
explained earlier in the paragraph.

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

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

> 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?
>
This a good point - we will take a look at them.

> 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?
>
Yes that probably needs a small clarification. We're basically saying
that they're
both supported - though not necessarily configured as yet,

Thanks,

Piers.

> Regards!
> -Qin
>
>
> ----- Original Message -----
> From: Roni Even
> To: avt@ietf.org
> 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
>
>
>
> Please review the draft and send comments to the list.
>
>
>
>
>
> Roni Even
>
>
>
>
>
>
>
> ________________________________
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt
>
>