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

[Qin Wu <[e-mail]>]

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" <[e-mail]>
To: "Qin Wu" <[e-mail]>
Cc: "Roni Even" <[e-mail]>; <[e-mail]>; "Magnus Westerlund" <[e-mail]>
Sent: Friday, October 14, 2011 10:54 PM
Subject: 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 <[e-mail]> 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.

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

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

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

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

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


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

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


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

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

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

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

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

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

> Regards!
> -Qin
>
>
> ----- Original Message -----
> From: Roni Even
> To: [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt
>
>