Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04 - more
Magnus Westerlund <magnus.westerlund@ericsson.com> Thu, 27 October 2011 13:36 UTC
Return-Path: <magnus.westerlund@ericsson.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 2CBDF21F8532 for <avt@ietfa.amsl.com>; Thu, 27 Oct 2011 06:36:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.558
X-Spam-Level:
X-Spam-Status: No, score=-106.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, 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 cbJQpyZdbpES for <avt@ietfa.amsl.com>; Thu, 27 Oct 2011 06:36:00 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id AE64C21F84CF for <avt@ietf.org>; Thu, 27 Oct 2011 06:35:59 -0700 (PDT)
X-AuditID: c1b4fb39-b7bfdae000005125-74-4ea95e3e60f2
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 00.9B.20773.E3E59AE4; Thu, 27 Oct 2011 15:35:58 +0200 (CEST)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Thu, 27 Oct 2011 15:35:58 +0200
Message-ID: <4EA95E3C.2020907@ericsson.com>
Date: Thu, 27 Oct 2011 15:35:56 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Roni Even <Even.roni@huawei.com>
References: <016101cc7f6c$9795e380$c6c1aa80$%roni@huawei.com> <06ad01cc90b2$e6b4d190$b41e74b0$%roni@huawei.com>
In-Reply-To: <06ad01cc90b2$e6b4d190$b41e74b0$%roni@huawei.com>
X-Enigmail-Version: 1.3.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
Cc: "avt@ietf.org" <avt@ietf.org>
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: Thu, 27 Oct 2011 13:36:01 -0000
Hi Roni, Thanks for the feedback. On 2011-10-22 14:05, Roni Even wrote: > > 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. sure. > > 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. I would suggest to formulate this as: If support for both in-band and out-of-band mechanisms are signalled, the sender when negotiating SHOULD offer detection of ECT using STUN with ICE with higher priority than detection of ECT using RTP and RTCP. > > 3. In section 7.2.1 y ou refer not reference the keep-alive RFC Why do you think we should reference RFC 6263? Is is because we discuss which packets would have least impact on the media flow when used as ECT probes? IF that is the reasons I don't think RFC6263 has much to offer. The outcome of this document is that nothing short of real RTP or RTCP packets work well for keep-alive. And in this context of ECN we can't use the RTCP packets. > > 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. Because if we use SHOULD then one might consider that additional exceptions than just that one exists. And that is not the case. If you use a method that requires timely feedback, then you better send that feedback. > > 5. In section 7.2.1 "ECN initiation is considered to have failed > at the instant when a ny RTP s 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. I think you are misunderstanding what was written, maybe because of the bad formulation in the sentence. I have rewritten this to: ECN initiation is considered to have failed at the instant the initiating RTP sender received an RTCP packet that doesn't contain an RTCP ECN feedback report or ECN summary report from any RTP session participant that has an RTCP RR with an extended RTP sequence number field that indicates that it should have received multiple (>3) ECT marked RTP packets. Is that clearer? > > 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. I am very split about discussing this. I know there exist implementations that uses TMMBR as primary congestion control. However, RFC 5104 hasn't specified it in that way. I also see an issue with bringing it up in this context, namely that we bless this without any specification or requirements on the solution. For example how responsive to congestion is the usage of TMMBR. One parameter is the AVPF operations mode and due to this RTCP bandwidths. another is the algorithm determining the appropriate bit-rate. I know that the multicast scalable encoding share similar concerns but there we have even less alternatives. I think reformulating the introduction of the section to make clear that this is just an example of Receiver driven congestion control is most appropriate. In a receiver driven congestion control mechanism, the receivers can react to the ECN-CE marks themselves without providing ECN-CE feedback to the sender. This may allow faster response than sender-driven congestion control in some circumstances and also scale to large number of receivers and multicast usage. One example of receiver-driven congestion control is implemented by providing the content in a layered way, with each layer providing improved media quality but also increased bandwidth usage. > > 7.&nbs ; In section 10.6 you use the wrong range definition "From RFC > 5389: STUN Attribute types in the first half of the > comprehension-requiredrange (0x0000 - 0x3FFF) and in the first half of > the comprehension- optional range (0x8000 - 0xBFFF) are assigned by IETF > Review" > Good catch. Thanks Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ----------------------------------------------------------------------
- [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-… Roni Even
- Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-… Belling, Thomas (NSN - DE/Munich)
- Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-… Magnus Westerlund
- Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-… Qin Wu
- Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-… Belling, Thomas (NSN - DE/Munich)
- Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-… Qin Wu
- Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-… Bill Ver Steeg (versteb)
- Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-… Dan Wing
- Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-… Piers O'Hanlon
- Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-… Qin Wu
- Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-… Magnus Westerlund
- Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-… Magnus Westerlund
- Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-… Magnus Westerlund
- Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-… Dan Wing
- Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-… Piers O'Hanlon
- [AVTCORE] 答复: WGLC on draft-ietf-avtcore-ecn-for-… Qin Wu
- Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-… Roni Even
- Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-… Roni Even
- Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-… Belling, Thomas (NSN - DE/Munich)
- Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-… Magnus Westerlund
- Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-… Roni Even
- Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-… Bill Ver Steeg (versteb)
- Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-… Piers O'Hanlon
- Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-… Bill Ver Steeg (versteb)
- Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-… Piers O'Hanlon