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

Roni Even <Even.roni@huawei.com> Sat, 22 October 2011 12:08 UTC

Return-Path: <Even.roni@huawei.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD5821F84D5 for <avt@ietfa.amsl.com>; Sat, 22 Oct 2011 05:08:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.73
X-Spam-Level:
X-Spam-Status: No, score=-105.73 tagged_above=-999 required=5 tests=[AWL=-0.395, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.263, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wdm2WyGFnJgO for <avt@ietfa.amsl.com>; Sat, 22 Oct 2011 05:08:19 -0700 (PDT)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 845F621F84CE for <avt@ietf.org>; Sat, 22 Oct 2011 05:08:18 -0700 (PDT)
Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTG00EVKV1RS3@szxga05-in.huawei.com> for avt@ietf.org; Sat, 22 Oct 2011 20:08:15 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTG00II7V1QBS@szxga05-in.huawei.com> for avt@ietf.org; Sat, 22 Oct 2011 20:08:15 +0800 (CST)
Received: from windows8d787f9 (bzq-79-183-199-250.red.bezeqint.net [79.183.199.250]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LTG00E09V1959@szxml12-in.huawei.com> for avt@ietf.org; Sat, 22 Oct 2011 20:08:14 +0800 (CST)
Date: Sat, 22 Oct 2011 14:05:20 +0200
From: Roni Even <Even.roni@huawei.com>
In-reply-to: <016101cc7f6c$9795e380$c6c1aa80$%roni@huawei.com>
To: avt@ietf.org
Message-id: <06ad01cc90b2$e6b4d190$b41e74b0$%roni@huawei.com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-type: multipart/alternative; boundary="Boundary_(ID_8C5biREOc56ME8Wt5aHCXQ)"
Content-language: en-us
Thread-index: Acx/bJMAZn1O9EdQQ6OkqDNm9OOyyQRQ5naA
iPlanet-SMTP-Warning: Lines longer than SMTP allows found and truncated.
References: <016101cc7f6c$9795e380$c6c1aa80$%roni@huawei.com>
Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04 - more
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 22 Oct 2011 12:08:20 -0000

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

 

 

 

 

 

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Roni
Even
Sent: Friday, September 30, 2011 3:29 PM
To: avt@ietf.org
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

 

 

 

  _____