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

"Belling, Thomas (NSN - DE/Munich)" <thomas.belling@nsn.com> Tue, 11 October 2011 15:14 UTC

Return-Path: <thomas.belling@nsn.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 EA17A21F8E28 for <avt@ietfa.amsl.com>; Tue, 11 Oct 2011 08:14:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.298
X-Spam-Level:
X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_LIST=2.3, RCVD_IN_DNSWL_MED=-4]
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 D41vNbpsv4HQ for <avt@ietfa.amsl.com>; Tue, 11 Oct 2011 08:14:24 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF3221F8E23 for <avt@ietf.org>; Tue, 11 Oct 2011 08:14:23 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p9BFED76007317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 11 Oct 2011 17:14:13 +0200
Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p9BFECAV031881; Tue, 11 Oct 2011 17:14:12 +0200
Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 Oct 2011 17:14:12 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC8828.6EA9F332"
Date: Tue, 11 Oct 2011 17:14:12 +0200
Message-ID: <1A8A7D59006A8240B27FF63C794CA57F98549C@DEMUEXC014.nsn-intra.net>
In-Reply-To: <76AADF1A61784B52A8516E16AAF78E71@china.huawei.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04
Thread-Index: AcyHwHxs/U3+y8TaT2ammrvk+OA0TwAM8xqg
References: <016101cc7f6c$9795e380$c6c1aa80$%roni@huawei.com> <76AADF1A61784B52A8516E16AAF78E71@china.huawei.com>
From: "Belling, Thomas (NSN - DE/Munich)" <thomas.belling@nsn.com>
To: ext Qin Wu <bill.wu@huawei.com>, Roni Even <Even.roni@huawei.com>, avt@ietf.org
X-OriginalArrivalTime: 11 Oct 2011 15:14:12.0752 (UTC) FILETIME=[6EE5B900:01CC8828]
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>
Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04
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: Tue, 11 Oct 2011 15:14:27 -0000

 

Dear Qin, Magnus,

 

Some replies to some of the earlier comments (I only briefly checked the
rest).

 

Thomas

 

 

3. Section 3, 2nd paragraph

"

   Counting vs Detecting Congestion:  TCP and the protocols derived from
   it are mainly designed to respond the same whether they experience
   a burst of congestion indications within one RTT or just one.

"

[Qin]: What's the difference between "one RTT" and "just one"?

 

[Thomas] Intention seems rather to be "just one congestion indication".

 

 

7. Section 3.2, 5th paragraph

"

The standard RTP/ AVP profile [RFC3551] does not allow any early or
immediate
transmission of RTCP feedback, and has a minimal RTCP interval whose
default value

 (5 seconds) is many times the normal RTT between sender and receiver.

"

[Qin]: What's the purpose of last sentence of this paragraph?
       Are you saying RFC3551 following Regular RTCP timing rule?
       or something else?

 

   Another question is according to RFC3551, the negotiation of
   parameters or membership control may be not support. in other wonder,
   there may be no way to negotiate ECN with RTP using SDP signaling,
   I am wondering can we say ECN with RTP can be used with the standard
RTP/
   AVP profile [RFC3551]. 

 

[Thomas] Negotiation is done with the 'ecn-capable-rtp' SDP attribute
defined is this draft. Implantations not supporting ECN would ignore
this, But this is independent of AVP or AVPF. 

 

 

8. Section 3.3,3rd paragraph

"

   For interoperability we mandate the implementation of the RTP/AVPF
   profile, with both RTCP extensions and the necessary signalling to
   support a common operations mode.  This specification recommends the
   use of RTP/AVPF in all cases as negotiation of the common
   interoperability point requires RTP/AVPF, mixed negotiation of RTP/
   AVP and RTP/AVPF depending on other SDP attributes in the same media
   block is difficult,

"

[Qin] How mixed negotiation is avoided when you don't put all the SDP
attribute
 into the same media block? I don't really understand the rationale.
Would you
like to clarify a little bit?

 

[Thomas] SDP capneg allows offering AVPF and AVP in the same media
block, and also to relate SDP attributes to one of the transports only.
Trouble is that this is not yet supported everywhere and has its
problems with traversing intermediates not supporting it.

 

 

11. Section 4, 3rd paragraph

"

   o  The sender may generate a (small) subset of its RTP data packets
      with the ECN field set to ECT(0) or ECT(1). 

"

 

[Qin] It is not clear to me where the ECN field is located.
Is ECN field in the IP header or UDP header or RTP header?

 

[Thomas] It is the IP header. Text could be modified accordingly, e.g.: 

    o  The sender may generate a (small) subset of its RTP data packets
      with the ECN IP header field set to ECT(0) or ECT(1). 

 

 

13.Section 5.1,1st paragraph

"

   This RTP/AVPF transport layer feedback format is intended for use in
   RTP/AVPF early or immediate feedback modes when information needs to
   urgently reach the sender.  Thus its main use is to report reception
   of an ECN-CE marked RTP packet so that the sender may perform
   congestion control, or to speed up the initiation procedures by
   rapidly reporting that the path can support ECN-marked traffic.

"

 

[Qin]: are you saying slow initiation procedure may result in network
congestion?
In my understanding, when ECN-CE marked packet is received, the only
choice for sender
is to do congestion control since you are not sure if initiation
procedure lead to such
congestion. If it is not intiation procedure that lead to congestion,
you get risk to worse
congestion condition? 

 

[Thomas] I believe this does not only refer to initiation, but mainly to
feedback if congestion is encountered after the ECN media flow has been
established.

 

 

 

 

Regards!

-Qin

 

	----- Original Message ----- 

	From: Roni Even <mailto:Even.roni@huawei.com>  

	To: avt@ietf.org 

	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
	avt@ietf.org
	https://www.ietf.org/mailman/listinfo/avt