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

["Piers O'Hanlon" <[e-mail]>]

Hi Qin

Comments inline.

On 18 October 2011 07:14, Qin Wu <[e-mail]> wrote:
> 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.
>
I can understand your concern but I think it is clear enough as is.

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

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

>
>> 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?
>
I'm sorry you're correct here (I initially looked at the wrong 'then').

>> 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?
>
I can understand that one may confuse the meaning but I think it ok as is.

>> 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.
>
We could add that clarification.

Thanks again,

Piers.

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