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