As follow up, the corresponding pseud= ocode and ns-2 simulation code + README can be found here -- ftp://ftpeng.cisco.com/fred/ropan/

Best,

Preethi (on behalf of co-authors). --B_3445410382_13533825-- From naeem.khademi@gmail.com Wed Mar 6 12:31:54 2013 Return-Path: X-Original-To: iccrg@ietfa.amsl.com Delivered-To: iccrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A4421F845D for ; Wed, 6 Mar 2013 12:31:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 X2Kc92jVOwFa for ; Wed, 6 Mar 2013 12:31:48 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9A03B21F844C for ; Wed, 6 Mar 2013 12:31:48 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id l10so6251906eei.3 for ; Wed, 06 Mar 2013 12:31:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=fclUFib4j4/qfOuYm+a+5u+H0S1gz8TWZQYWaIOhAGo=; b=TkI287t5eKc1aXV/fDNFqLFCJppJj7xAgxqkI5dXKumEjiQN+aEJymrkp79AE46p+A 9fyoeJz7tYa/07KAt9LoqrOQSRBW6lGTHQR8e3sExdgGp6C12aeCt5+TRyqeeJOmyOJ6 nC8M2eq4+5nQP4iU7jXk2CSSzwUbkZFEi/r5eYrZKMEMhTFv55v9moSEea/cAzylJTKI 3gKo+WO1J+AsvejzeT+D/wyinr6LhfjPhZJ3CETMTPtGxec4z1gFYE1iWprOawkpixp9 Oi03Q+o+NH9PuUnNecjEDB2lA1PzeDLXneprMJZA1Mrm691KDvyH1JRaFdPN/pVGFEH+ xqeg== MIME-Version: 1.0 X-Received: by 10.14.193.134 with SMTP id k6mr85739761een.37.1362601906595; Wed, 06 Mar 2013 12:31:46 -0800 (PST) Received: by 10.14.137.12 with HTTP; Wed, 6 Mar 2013 12:31:46 -0800 (PST) Date: Wed, 6 Mar 2013 21:31:46 +0100 Message-ID: From: Naeem Khademi To: iccrg@irtf.org Content-Type: multipart/alternative; boundary=047d7b343e2a9d193704d7477aeb Subject: [iccrg] PIE Simulation Code X-BeenThere: iccrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussions of Internet Congestion Control Research Group \(ICCRG\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 20:31:54 -0000 --047d7b343e2a9d193704d7477aeb Content-Type: text/plain; charset=ISO-8859-1 Hi Thanks a lot! that's a very good news as the folks can now start testing PIE versus fq_codel and other AQMs. Any chance of a Linux module patch for PIE some time soon? Regards, Naeem Khademi ---------- Forwarded message ---------- > From: Preethi Natarajan > To: , > Cc: > Date: Wed, 06 Mar 2013 10:26:19 -0800 > Subject: [iccrg] PIE Simulation Code > Hi all, > > Few weeks ago, the PIE (Proportional Integral Controller Enhanced) AQM > scheme was described in this initial draft -- > http://tools.ietf.org/html/draft-pan-tsvwg-pie-00. > > As follow up, the corresponding pseudocode and ns-2 simulation code + > README can be found here -- ftp://ftpeng.cisco.com/fred/ropan/ > > Best, > Preethi (on behalf of co-authors). > > _______________________________________________ > iccrg mailing list > iccrg@irtf.org > https://www.irtf.org/mailman/listinfo/iccrg > > --047d7b343e2a9d193704d7477aeb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi=A0

Thanks a lot! that's a very good news as the f= olks can now start testing PIE versus fq_codel and other AQMs. Any chance o= f a Linux module patch for PIE some time soon? =A0=A0

<= div> Regards,

Naeem Khademi

<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">---------- Forwarded message ----------
Fr= om:=A0Preethi Natarajan <preeth= i.cis@gmail.com>
To:=A0<tsvwg@ietf.org>, <iccrg@irtf.org>
Cc:=A0
Date:=A0= Wed, 06 Mar 2013 10:26:19 -0800
Subject:=A0[iccrg] PIE Simulation Code

Hi all,

Few weeks ago, the PIE (Proportional = Integral Controller Enhanced) AQM scheme was described in this initial draf= t --=A0http://tools.ietf.org/html/draft-pan-tsvwg-pie-00.

As follow up, the corresponding pseudocode and ns-2 sim= ulation code + README can be found here --=A0ftp://ftpeng.cisco.com/fred/ropan/

Best,

Preethi (on behalf of co-authors).

_______________________________________________
iccrg mailing list
iccrg@irtf.org
h= ttps://www.irtf.org/mailman/listinfo/iccrg

--047d7b343e2a9d193704d7477aeb-- From preethi.cis@gmail.com Wed Mar 6 12:42:03 2013 Return-Path: X-Original-To: iccrg@ietfa.amsl.com Delivered-To: iccrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7B3811E80FF for ; Wed, 6 Mar 2013 12:42:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] 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 Tw2aMMDW0JfL for ; Wed, 6 Mar 2013 12:41:58 -0800 (PST) Received: from mail-pb0-f49.google.com (mail-pb0-f49.google.com [209.85.160.49]) by ietfa.amsl.com (Postfix) with ESMTP id E00C111E80BA for ; Wed, 6 Mar 2013 12:41:58 -0800 (PST) Received: by mail-pb0-f49.google.com with SMTP id xa12so6560476pbc.36 for ; Wed, 06 Mar 2013 12:41:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:user-agent:date:subject:from:to:cc:message-id :thread-topic:in-reply-to:mime-version:content-type; bh=ge9R33hY6V0DmYjLAkUQRsDAnX2aD1QZ9eTIyQkoI2Y=; b=hLtSauKx2ehIjkZhTGvcCabOeH6TlwImZe+nRWBxa/JzRPqiFrVDQGN5bhAWlNBUfv j/JufB+Xqltoa+N6HWc4I3quw2mI7LrdMx/UniaMjSl8J+UdYXcd4MzrCnuUIFVgSGd7 RRgPVYaxT77bpj2BM2wdpC7OTEY2NXELjfSJgW4QMenUU8p/WYcX0/GGWz2q9QvQkZRK iRi5BJZkWYAyje9CFYCgsLmGUWsScsdDKEX7rPjKhJQ/biCqBlDlmjp5HooeknHih1uz olVAZl+gVi/2fprZiJY2X8LtcZIl1+EBF7FJ+QMzMB8b2DIkw/N9aMJgCzOn06zkI/H8 8z8A== X-Received: by 10.68.63.194 with SMTP id i2mr50604856pbs.4.1362602518522; Wed, 06 Mar 2013 12:41:58 -0800 (PST) Received: from [10.33.22.215] (128-107-239-234.cisco.com. [128.107.239.234]) by mx.google.com with ESMTPS id kt5sm32733859pbc.30.2013.03.06.12.41.54 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 06 Mar 2013 12:41:57 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.2.1.120420 Date: Wed, 06 Mar 2013 12:41:51 -0800 From: Preethi Natarajan To: Naeem Khademi , Message-ID: Thread-Topic: [iccrg] PIE Simulation Code In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3445418516_14034675" Cc: "Rong Pan \(ropan\)" , "Fred Baker \(fred\)" , "Chiara Piglione \(cpiglion\)" , "Mythili Suryanarayana Prabhu \(mysuryan\)" , "Vijay Subramanian \(vijaynsu\)" Subject: Re: [iccrg] PIE Simulation Code X-BeenThere: iccrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussions of Internet Congestion Control Research Group \(ICCRG\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 20:42:03 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3445418516_14034675 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Naeem, Thanks for your interest. Yes, we do have PIE implementation as a Linux module, and we plan to make this publicly available. We are fielding a few legal issues on this front. Hopefully we can get the code out in a few weeks. Best, Preethi From: Naeem Khademi Date: Wednesday, March 6, 2013 12:31 PM To: Subject: [iccrg] PIE Simulation Code Hi Thanks a lot! that's a very good news as the folks can now start testing PIE versus fq_codel and other AQMs. Any chance of a Linux module patch for PIE some time soon? Regards, Naeem Khademi > ---------- Forwarded message ---------- > From: Preethi Natarajan > To: , > Cc: > Date: Wed, 06 Mar 2013 10:26:19 -0800 > Subject: [iccrg] PIE Simulation Code > Hi all, > > Few weeks ago, the PIE (Proportional Integral Controller Enhanced) AQM scheme > was described in this initial draft -- > http://tools.ietf.org/html/draft-pan-tsvwg-pie-00. > > As follow up, the corresponding pseudocode and ns-2 simulation code + README > can be found here -- ftp://ftpeng.cisco.com/fred/ropan/ > > Best, > Preethi (on behalf of co-authors). > > _______________________________________________ > iccrg mailing list > iccrg@irtf.org > https://www.irtf.org/mailman/listinfo/iccrg > _______________________________________________ iccrg mailing list iccrg@irtf.org https://www.irtf.org/mailman/listinfo/iccrg --B_3445418516_14034675 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable

Hi Naeem,

Thanks for your interest.

Yes, we do h= ave PIE implementation as a Linux module, and we plan to make this publicly = available. We are fielding a few legal issues on this front. Hopefully we ca= n get the code out in a few weeks.

Best,

= Preethi

From: Naeem = Khademi <naeem.khademi@gmail.com= >
Date: Wednesday, March 6,= 2013 12:31 PM
To: <iccrg@irtf.org>
Subject: [iccrg] PIE Simulation Code

Hi&n= bsp;

Thanks a lot! that's a very good news as the folks c= an now start testing PIE versus fq_codel and other AQMs. Any chance of a Lin= ux module patch for PIE some time soon?

Regards,

Naeem Khademi

---------- Forwarded message ----------
From: = ;Preethi Natarajan <preethi.cis@gm= ail.com>
To: <tsvwg@ietf.org>, <iccrg@irtf.org>
Cc:
Date:&n= bsp;Wed, 06 Mar 2013 10:26:19 -0800
Subject: [iccrg] PIE Simulation = Code

Hi all,

Few weeks ago, the PIE (Pr= oportional Integral Controller Enhanced) AQM scheme was described in this in= itial draft -- http://tools.ietf.org/html/draft-pan-tsvwg-pie-00.

As follow up, the corresponding pseudocode and ns-2 = simulation code + README can be found here -- ftp://ftpeng.cisco.com/fred/ropan/

Best,

Preethi (on behalf of co-authors).

_______________________________________________
iccrg mailing list
iccrg@irtf.orghttps= ://www.irtf.org/mailman/listinfo/iccrg

_______________________________________________ iccrg mailing list iccrg@irtf.org https://www.irtf.org/= mailman/listinfo/iccrg --B_3445418516_14034675-- From g.white@CableLabs.com Thu Mar 7 21:29:30 2013 Return-Path: X-Original-To: iccrg@ietfa.amsl.com Delivered-To: iccrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 524BB21F8654 for ; Thu, 7 Mar 2013 21:29:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 mlCtxdN+XbJA for ; Thu, 7 Mar 2013 21:29:29 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id A733721F863B for ; Thu, 7 Mar 2013 21:29:26 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id r285TJmI006509; Thu, 7 Mar 2013 22:29:19 -0700 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Thu, 07 Mar 2013 22:29:19 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee]) by EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee%11]) with mapi id 14.02.0328.009; Thu, 7 Mar 2013 22:29:16 -0700 From: Greg White To: Michael Welzl Thread-Topic: [iccrg] Draft agenda available Thread-Index: AQHOFO2dggT2f5RrhEm0WWyyziZvtJibUeWD Date: Fri, 8 Mar 2013 05:29:16 +0000 Message-ID: <2BE3B3C2-71F5-4BA9-9FD6-97CA7AB81637@cablelabs.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Cc: "iccrg@irtf.org" Subject: Re: [iccrg] Draft agenda available X-BeenThere: iccrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussions of Internet Congestion Control Research Group \(ICCRG\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 05:29:30 -0000 Michael, It looks like there may be a few remaining minutes in the agenda. If so, I'= d like to give a brief update on our simulation study of AQM performance in= DOCSIS 3.0. I shared some initial results at bits-n-bites in Atlanta, and= now have views on CoDel, sfq_codel, and some early results with PIE.=20 Subject-wise it might fit well wedged in between Toke and Matt, but that's = your call. I can keep it short so as not to steal time from those who were = more organized about requesting a slot.=20 Thanks, Greg On Feb 27, 2013, at 6:23 AM, "Michael Welzl" wrote: > Hi, >=20 > The draft agenda is now available at: > http://www.ietf.org/proceedings/86/agenda/agenda-86-iccrg >=20 > and below. As you can see, there is still space available - send us your = requests! >=20 > Cheers, > Michael >=20 > *** >=20 > ICCRG agenda, IETF #84 > Tuesday, March 12 2013, 13:00-15:00, room Caribbean 6 >=20 >=20 > Rong Pan: "A follow up on the PIE queue management algorithm", 30 min >=20 > Toke Hoeiland-Joergensen: "The State of the Art in Bufferbloat Testing an= d Reduction on Linux", 30 min >=20 > _______________________________________________ > iccrg mailing list > iccrg@irtf.org > https://www.irtf.org/mailman/listinfo/iccrg From michawe@ifi.uio.no Thu Mar 7 22:13:10 2013 Return-Path: X-Original-To: iccrg@ietfa.amsl.com Delivered-To: iccrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE8AB21F8505 for ; Thu, 7 Mar 2013 22:13:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.952 X-Spam-Level: X-Spam-Status: No, score=-100.952 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 EfghtIKlcDPE for ; Thu, 7 Mar 2013 22:13:10 -0800 (PST) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id F130321F869E for ; Thu, 7 Mar 2013 22:13:09 -0800 (PST) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1UDqYH-00050P-4d; Fri, 08 Mar 2013 07:13:09 +0100 Received: from 213.246.16.62.customer.cdi.no ([62.16.246.213] helo=[192.168.0.103]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1UDqYG-0007xU-HH; Fri, 08 Mar 2013 07:13:09 +0100 References: <2BE3B3C2-71F5-4BA9-9FD6-97CA7AB81637@cablelabs.com> In-Reply-To: <2BE3B3C2-71F5-4BA9-9FD6-97CA7AB81637@cablelabs.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (9B206) From: Michael Welzl Date: Fri, 8 Mar 2013 07:13:06 +0100 To: Greg White X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 2 sum msgs/h 1 total rcpts 2606 max rcpts/h 20 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, MIME_QP_LONG_LINE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 58915462B768D855733A605A99F655FC68694C93 X-UiO-SPAM-Test: remote_host: 62.16.246.213 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 267 max/h 8 blacklist 0 greylist 0 ratelimit 0 Cc: "iccrg@irtf.org" Subject: Re: [iccrg] Draft agenda available X-BeenThere: iccrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussions of Internet Congestion Control Research Group \(ICCRG\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 06:13:11 -0000 Definitely welcome + i agree about the agenda position Sent from my iPhone On 8. mars 2013, at 06:29, Greg White wrote: > Michael, >=20 > It looks like there may be a few remaining minutes in the agenda. If so, I= 'd like to give a brief update on our simulation study of AQM performance in= DOCSIS 3.0. I shared some initial results at bits-n-bites in Atlanta, and n= ow have views on CoDel, sfq_codel, and some early results with PIE.=20 >=20 > Subject-wise it might fit well wedged in between Toke and Matt, but that's= your call. I can keep it short so as not to steal time from those who were m= ore organized about requesting a slot.=20 >=20 > Thanks, > Greg >=20 > On Feb 27, 2013, at 6:23 AM, "Michael Welzl" wrote: >=20 >> Hi, >>=20 >> The draft agenda is now available at: >> http://www.ietf.org/proceedings/86/agenda/agenda-86-iccrg >>=20 >> and below. As you can see, there is still space available - send us your r= equests! >>=20 >> Cheers, >> Michael >>=20 >> *** >>=20 >> ICCRG agenda, IETF #84 >> Tuesday, March 12 2013, 13:00-15:00, room Caribbean 6 >>=20 >>=20 >> Rong Pan: "A follow up on the PIE queue management algorithm", 30 min >>=20 >> Toke Hoeiland-Joergensen: "The State of the Art in Bufferbloat Testing an= d Reduction on Linux", 30 min >>=20 >> _______________________________________________ >> iccrg mailing list >> iccrg@irtf.org >> https://www.irtf.org/mailman/listinfo/iccrg > _______________________________________________ > iccrg mailing list > iccrg@irtf.org > https://www.irtf.org/mailman/listinfo/iccrg From david.ros@telecom-bretagne.eu Mon Mar 11 12:01:59 2013 Return-Path: X-Original-To: iccrg@ietfa.amsl.com Delivered-To: iccrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E144411E814E for ; Mon, 11 Mar 2013 12:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 KMh3uytW0uQM for ; Mon, 11 Mar 2013 12:01:59 -0700 (PDT) Received: from zproxy210.enst-bretagne.fr (zproxy210.enst-bretagne.fr [192.108.117.8]) by ietfa.amsl.com (Postfix) with ESMTP id C7E0411E8214 for ; Mon, 11 Mar 2013 12:01:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zproxy210.enst-bretagne.fr (Postfix) with ESMTP id 9436566035 for ; Mon, 11 Mar 2013 20:01:54 +0100 (CET) X-Virus-Scanned: amavisd-new at zproxy210.enst-bretagne.fr Received: from zproxy210.enst-bretagne.fr ([127.0.0.1]) by localhost (zproxy210.enst-bretagne.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id udezkxIR+kcD for ; Mon, 11 Mar 2013 20:01:54 +0100 (CET) Received: from dhcp-5506.meeting.ietf.org (dhcp-5506.meeting.ietf.org [130.129.85.6]) by zproxy210.enst-bretagne.fr (Postfix) with ESMTPSA id 21ABC6600C for ; Mon, 11 Mar 2013 20:01:54 +0100 (CET) From: David Ros Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 11 Mar 2013 15:01:52 -0400 Message-Id: <89C5F951-5989-4478-8E59-593528A439BF@telecom-bretagne.eu> To: iccrg@irtf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [iccrg] looking for minute takers / jabber scribes X-BeenThere: iccrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussions of Internet Congestion Control Research Group \(ICCRG\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 19:02:00 -0000 Hi, We are looking for minute takers & jabber scribes for tomorrow's ICCRG = meeting. Any volunteers, please let us know. Thanks, David =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David ROS http://www.rennes.enst-bretagne.fr/~dros/ "But we're a university! [...] What sort of people would we be if we = didn't go into the Library?" "Students." -- Terry Pratchett From mirja.kuehlewind@ikr.uni-stuttgart.de Tue Mar 19 01:04:36 2013 Return-Path: X-Original-To: iccrg@ietfa.amsl.com Delivered-To: iccrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B164521F8A6F for ; Tue, 19 Mar 2013 01:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.892 X-Spam-Level: X-Spam-Status: No, score=-0.892 tagged_above=-999 required=5 tests=[AWL=-1.357, BAYES_40=-0.185, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] 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 wPAviPRnwX13 for ; Tue, 19 Mar 2013 01:04:36 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB6621F8A71 for ; Tue, 19 Mar 2013 01:04:35 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id BA624600F5; Tue, 19 Mar 2013 09:04:33 +0100 (CET) Received: from vpn-2-cl195 (vpn-2-cl195 [10.41.21.195]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 614AE600F4; Tue, 19 Mar 2013 09:04:33 +0100 (CET) From: Mirja =?iso-8859-1?q?K=FChlewind?= To: iccrg@irtf.org, tcpm@ietf.org, aqm@ietf.org, Brian Trammell Date: Tue, 19 Mar 2013 09:04:32 +0100 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201303190904.32180.mkuehle@ikr.uni-stuttgart.de> Subject: [iccrg] ECN support and usage on the Internet X-BeenThere: iccrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussions of Internet Congestion Control Research Group \(ICCRG\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 08:04:36 -0000 Hi everybody, we just published a paper on the state of ECN support and usage on the=20 Internet. We performed a similar study than Bauer et al., probing webserver= s=20 to get the current status. We found that about 30% of webservers (by Sep'12= )=20 support ECN. Unfortunately, still we saw a failure rate of 9% when checking end-2-end path ECN usability (setting CE). Additionally, we analyzed NetFlo= w=20 data to get a lower bound for the ECN usage which was below 1%. Then we als= o=20 had a look at IPv6 (47,5% ECN support). At the same time we also monitored = an=20 increase in general IPv6 support on webserver over the IPv6 launch day last= =20 year (-> check the paper). K=FChlewind, M.; Neuner, S.; Trammell, B.: On the state of ECN and TCP Opti= ons=20 on the Internet. Proceedings of the 14th Passive and Active Measurement=20 conference (PAM 2013), Hong Kong, March 2013. http://www.ikr.uni-stuttgart.de/Content/Publications/Archive/Kue_PAM13_4016= 0.pdf Do we need to start a campaign to further encourage greater ECN support (al= so=20 of network providers)? Asking the content providers on the list(s): What ar= e=20 the reasons to not enable ECN support? Mirja From swmike@swm.pp.se Tue Mar 19 02:22:55 2013 Return-Path: X-Original-To: iccrg@ietfa.amsl.com Delivered-To: iccrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AAF321F89CC for ; Tue, 19 Mar 2013 02:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.43 X-Spam-Level: X-Spam-Status: No, score=-2.43 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 9EqrNLauey31 for ; Tue, 19 Mar 2013 02:22:54 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE5321F8995 for ; Tue, 19 Mar 2013 02:22:54 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 9711C9C; Tue, 19 Mar 2013 10:22:52 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 8C1049A; Tue, 19 Mar 2013 10:22:52 +0100 (CET) Date: Tue, 19 Mar 2013 10:22:52 +0100 (CET) From: Mikael Abrahamsson To: =?ISO-8859-15?Q?Mirja_K=FChlewind?= In-Reply-To: <201303190904.32180.mkuehle@ikr.uni-stuttgart.de> Message-ID: References: <201303190904.32180.mkuehle@ikr.uni-stuttgart.de> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-27937894-1363684972=:2309" Cc: tcpm@ietf.org, iccrg@irtf.org, aqm@ietf.org, Brian Trammell Subject: Re: [iccrg] [tcpm] ECN support and usage on the Internet X-BeenThere: iccrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussions of Internet Congestion Control Research Group \(ICCRG\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 09:22:55 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-27937894-1363684972=:2309 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Tue, 19 Mar 2013, Mirja K�hlewind wrote: > Do we need to start a campaign to further encourage greater ECN support > (also of network providers)? Asking the content providers on the > list(s): What are the reasons to not enable ECN support? Let me speculate: It's not on by default in Windows. There is little reason to turn it on, because "nobody" acts on ECN, and nobody acts on ECN because there is no demand for AQM, and even if there was AQM, it would most likely not be ECN enabled. I tried enabling ECN back in 2001 but saw major breakage. I re-enabled ECN again around 2008 or so and investigated, and at least the vendors I talked to didn't show much interest. I've been running with ECN on ever since and have not experienced any breakage I could trace back to ECN usage. This is hopeful. I believe the Bufferbloat discussions and increased interest in AQM on the customer access link will increase interest in ECN as well, so the important thing is that AQM document includes requirements for AQM, so when I request support for "best practice AQM", I get ECN support as well. I am looking for RFC6204 (Basic Requirements) style document. Then we need to advertise ECN benefit to end users, for instance by advocating its use through tools like . The change log says "Changed ECN Capability optimal recommendation in General tab based on user feedback and issues with some US ISPs" and I fear that the recommendation there is to turn ECN off :P. I don't want to install the utility to test. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-27937894-1363684972=:2309-- From gettysjim@gmail.com Tue Mar 19 10:26:25 2013 Return-Path: X-Original-To: iccrg@ietfa.amsl.com Delivered-To: iccrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2498B21F8D68 for ; Tue, 19 Mar 2013 10:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.311 X-Spam-Level: X-Spam-Status: No, score=-0.311 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] 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 tOzu86Hhh1ti for ; Tue, 19 Mar 2013 10:26:24 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 52F3321F8D1F for ; Tue, 19 Mar 2013 10:26:24 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id ta14so707855obb.0 for ; Tue, 19 Mar 2013 10:26:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=mND3ULikwWoEnVcQ+P37Wl9wGfSIEyyi03wC0s8ZhXI=; b=pmxPKfbCsBhDv0rjVutV1HHULppaVv9aFpZ8Vbst+hEnA3mrD9SU8xNoq4QR0BxlvV M2OX7hNxatsq907Z0U+VpwArYu3Oq1G3wObXvedrti4M/a4xpYKO8qW1hBE50oY1qQu9 KsUSwR+Yuz58lZfvZAYm2pw9ypSelycQL6sTC2Yd6zp1IhrZcGk/ooTaXbGe83OEMpiA c3CI41KKH2GaVLKkf+/FdXh8hhKTvetAQYVOXgwmSzlbznZa6ToUW2nSeizwYEg9zmh2 IfW1dvQqdVzVhevpxQ0d4cKlsKEGzaeHgqy7/RKX3DGnHb8nqlVYVj8ojliU0zvqc/rQ RI0w== MIME-Version: 1.0 X-Received: by 10.60.3.103 with SMTP id b7mr1850839oeb.86.1363713983726; Tue, 19 Mar 2013 10:26:23 -0700 (PDT) Sender: gettysjim@gmail.com Received: by 10.76.22.193 with HTTP; Tue, 19 Mar 2013 10:26:23 -0700 (PDT) In-Reply-To: <51487A27.7010904@hp.com> References: <201303190904.32180.mkuehle@ikr.uni-stuttgart.de> <51487A27.7010904@hp.com> Date: Tue, 19 Mar 2013 13:26:23 -0400 X-Google-Sender-Auth: ZkpC693eg7WCg6tnCpl7_b9NK-o Message-ID: From: Jim Gettys To: Rick Jones Content-Type: multipart/alternative; boundary=e89a8ff2514a934f0104d84a670e Cc: tcpm@ietf.org, aqm@ietf.org, iccrg@irtf.org, Mikael Abrahamsson Subject: Re: [iccrg] [tcpm] ECN support and usage on the Internet X-BeenThere: iccrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussions of Internet Congestion Control Research Group \(ICCRG\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 17:26:25 -0000 --e89a8ff2514a934f0104d84a670e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable You need to distinguish 1) "Will talk ECN when talked to", from 2) "Will initiate an ECN conversation". Linux, for example, will do 1) by default (and has for some time now), but requires configuration to turn on ECN when initiating a connection. - Jim On Tue, Mar 19, 2013 at 10:45 AM, Rick Jones wrote: > On 03/19/2013 02:22 AM, Mikael Abrahamsson wrote: > >> On Tue, 19 Mar 2013, Mirja K=FChlewind wrote: >> >> Do we need to start a campaign to further encourage greater ECN >>> support (also of network providers)? Asking the content providers on >>> the list(s): What are the reasons to not enable ECN support? >>> >> >> Let me speculate: >> >> It's not on by default in Windows. There is little reason to turn it on, >> because "nobody" acts on ECN, and nobody acts on ECN because there is no >> demand for AQM, and even if there was AQM, it would most likely not be >> ECN enabled. >> > > Out of curiosity, which stacks have ECN enabled by default? To my > recollection, on netperf.org I had to explicitly enable TCP's use of ECN > in the kernel which ships with Ubuntu 12.04. > > rick jones > > ______________________________**_________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/**listinfo/tcpm > --e89a8ff2514a934f0104d84a670e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

You need to distinguish 1) "Will talk ECN when talked= to", from 2) "Will initiate an ECN conversation".

<= /div>

Linux, for example, will do 1) by default (and has for some= time now), but requires configuration to turn on ECN when initiating a con= nection.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 - Jim

On Tue, Mar 19, 2013 at 10:45 AM, Rick Jones <= span dir=3D"ltr"><rick.jones2@hp.com> wrote:

On 03/19/2013 02:22 AM, Mi= kael Abrahamsson wrote:

On Tue, 19 Mar 2013, Mirja K=FChlewind wrote:

Do we need to start a campaign to further encourage greater ECN
support (also of network providers)? Asking the content providers on
the list(s): What are the reasons to not enable ECN support?

Let me speculate:

It's not on by default in Windows. There is little reason to turn it on= ,
because "nobody" acts on ECN, and nobody acts on ECN because ther= e is no
demand for AQM, and even if there was AQM, it would most likely not be
ECN enabled.

Out of curiosity, which stacks have ECN enabled by default? =A0To my recoll= ection, on netperf.org= I had to explicitly enable TCP's use of ECN in the kernel which ships = with Ubuntu 12.04.

rick jones

_______________________________________________
tcpm mailing list
tcpm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tcpm

--e89a8ff2514a934f0104d84a670e-- From ycheng@google.com Tue Mar 19 13:18:20 2013 Return-Path: X-Original-To: iccrg@ietfa.amsl.com Delivered-To: iccrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE42621F8E1A for ; Tue, 19 Mar 2013 13:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.678 X-Spam-Level: X-Spam-Status: No, score=-101.678 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, 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 f+G0+ESwDvQ1 for ; Tue, 19 Mar 2013 13:18:20 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id A75F021F8DB4 for ; Tue, 19 Mar 2013 13:18:19 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id fs13so1724619lab.8 for ; Tue, 19 Mar 2013 13:18:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=i6jaxFlFqeOCJNUT8xMntKYkSDYDu3W39alFwdf0Hrw=; b=aMdp+ik84QE/dH4ZmK9UnRCWquiPXxyM9amQpzvyprYdJE6UFGJXXj7PcPmC52JDNy wR2AO0LdZynUuFyW1DC1toCFMgawLn/AwvYlPg3FP3YaBFXAnkzv8MB6OQudkAbghZQu jTMTgoGvw40dZbx7d3s78MrggUjvK9aee+ecs27TMK27REEbIpOJ+hzIRAyBm0e/W1T5 GfgHxjmJGRehRTyYdVz04XI/vBnE3M8mcykNuxd7XsYiK+vMy+btpgHc5WQc3QQm/AAN d8bpqK86g5vgGQhY/Ya3i97Su2eFPJUN7gbvKWw5qO0cydQ4QXlxmXYKQXjzbQBZIDuy O21Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=i6jaxFlFqeOCJNUT8xMntKYkSDYDu3W39alFwdf0Hrw=; b=BXwM/pgs1oi169ECQn0m4wrjFZei2AyRzS/c9UkZLkaJUV/Cwy5bKe+nh5ES3Pc9z+ NspwuYvuW5uYEBhkGoTMnaBfqJRCmNn9RU1tvqr5dG5/IwNDmD4k4nyOtDl+xdetQa6D BHBm42WAa+QslBkTZGX55Z6PXP1oWcwsTcKizXb3zTxlxImXiEg4yGa9IZO2HpPPAtwb gxZElXP3DowFehJiwctaTUB4OuSYu2sE659MFqzDpSocPKHoFryXz48b5EeTC3oejEXl i8VP8N8R1wobRFzttIAMHUjHRmQzGHgJZD5vHXHsngHQWfRC7kyRDog0IM4/+0QqrJ5s AMhw== X-Received: by 10.112.88.35 with SMTP id bd3mr8700119lbb.56.1363724298428; Tue, 19 Mar 2013 13:18:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.52.48 with HTTP; Tue, 19 Mar 2013 13:17:57 -0700 (PDT) In-Reply-To: <201303190904.32180.mkuehle@ikr.uni-stuttgart.de> References: <201303190904.32180.mkuehle@ikr.uni-stuttgart.de> From: Yuchung Cheng Date: Tue, 19 Mar 2013 13:17:57 -0700 Message-ID: To: =?ISO-8859-1?Q?Mirja_K=FChlewind?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkdwZUm5bvIRZl9PTcEq4Xc1K8ufy1WVnV3tle2bK9JzVDyIrANrfUUl06kMQKS5K2B8B9j51NDfWtxhz6XTLE06jWQPj5Fo8ZS/QCkGCYsYlJ/S2aERWcsR1cYnQayK0SLV60nMOwxMAGkJJ/dGhsXbnjM972gZfyXNU287ak3YrjsaKiAquvVvB1dqO/GtJvii9k0 Cc: "tcpm@ietf.org Extensions" , iccrg@irtf.org, aqm@ietf.org, Brian Trammell Subject: Re: [iccrg] [tcpm] ECN support and usage on the Internet X-BeenThere: iccrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussions of Internet Congestion Control Research Group \(ICCRG\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 20:18:20 -0000 On Tue, Mar 19, 2013 at 1:04 AM, Mirja K=FChlewind wrote: > Hi everybody, > > we just published a paper on the state of ECN support and usage on the > Internet. We performed a similar study than Bauer et al., probing webserv= ers > to get the current status. We found that about 30% of webservers (by Sep'= 12) > support ECN. Unfortunately, still we saw a failure rate of 9% when checki= ng > end-2-end path ECN usability (setting CE). Additionally, we analyzed NetF= low > data to get a lower bound for the ECN usage which was below 1%. Then we a= lso > had a look at IPv6 (47,5% ECN support). At the same time we also monitore= d an > increase in general IPv6 support on webserver over the IPv6 launch day la= st > year (-> check the paper). > > K=FChlewind, M.; Neuner, S.; Trammell, B.: On the state of ECN and TCP Op= tions > on the Internet. Proceedings of the 14th Passive and Active Measurement > conference (PAM 2013), Hong Kong, March 2013. > > http://www.ikr.uni-stuttgart.de/Content/Publications/Archive/Kue_PAM13_40= 160.pdf Do people on the list know any (good) evaluation of performance impact of ECN on real and/or emulated networks. E.g., how much faster will the Web be if ECN is used (correctly). > > Do we need to start a campaign to further encourage greater ECN support (= also > of network providers)? Asking the content providers on the list(s): What = are > the reasons to not enable ECN support? > > Mirja > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From gettysjim@gmail.com Tue Mar 19 15:36:24 2013 Return-Path: X-Original-To: iccrg@ietfa.amsl.com Delivered-To: iccrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA3521F8A99 for ; Tue, 19 Mar 2013 15:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.217 X-Spam-Level: ** X-Spam-Status: No, score=2.217 tagged_above=-999 required=5 tests=[AWL=-5.041, BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_GB2312=1.345] 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 BzSnhBSFlJJM for ; Tue, 19 Mar 2013 15:36:20 -0700 (PDT) Received: from mail-oa0-f50.google.com (mail-oa0-f50.google.com [209.85.219.50]) by ietfa.amsl.com (Postfix) with ESMTP id E9A1C21F8A55 for ; Tue, 19 Mar 2013 15:36:19 -0700 (PDT) Received: by mail-oa0-f50.google.com with SMTP id l20so1113540oag.23 for ; Tue, 19 Mar 2013 15:36:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=nokrkxSBgc7Ypd2Gs9HvTnnYp8GAzuhWZVd+vkD5B4U=; b=PosXCTRJXu2PSDDkR1+OKkMYJPe7gwdCOch2xLNDooHdtBSfbygzMv1SlJHjjMkF2E p5X8PtadxbFOxGX9l9fDS5AT1o8ZhoueyZ52fb4D12NfkrpSGsXs+WZ0XdqTXqtcJrJ0 OGbmgqgmlED9tsmKfMea87ras0a+ajAxlY00PeIg4Wv0sgJz388Z/QvE5br1IQtrbWSM MbUQM8ziogMz5zPfT4lfCIAtrCXE3ZDOU5ZMoPdeATX3z8G3UdYUuH0XRTGgM4u+Qnea FfRSlGv5pM1UpCMhd4fVCg/ldpvZAQa5w3St9Kx+LmJ1MgoyNpUcpm3iTespW1CBvr+q B42Q== MIME-Version: 1.0 X-Received: by 10.60.3.71 with SMTP id a7mr2699262oea.35.1363732579347; Tue, 19 Mar 2013 15:36:19 -0700 (PDT) Sender: gettysjim@gmail.com Received: by 10.76.22.193 with HTTP; Tue, 19 Mar 2013 15:36:19 -0700 (PDT) In-Reply-To: References: <201303190904.32180.mkuehle@ikr.uni-stuttgart.de> <51487A27.7010904@hp.com>

Date: Tue, 19 Mar 2013 18:36:19 -0400 X-Google-Sender-Auth: --9eXhWCqOnC8mjcBV-gR9aVGYg Message-ID: From: Jim Gettys To: =?GB2312?B?zOzAvQ==?= Content-Type: multipart/alternative; boundary=e89a8f839d51f5f8c604d84ebb8b Cc: "tcpm@ietf.org" , Rick Jones , "aqm@ietf.org" , "iccrg@irtf.org" , Mikael Abrahamsson Subject: Re: [iccrg] =?gb2312?b?tPC4tDogIFt0Y3BtXSBFQ04gc3VwcG9ydCBhbmQgdXNh?= =?gb2312?b?Z2Ugb24gdGhlIEludGVybmV0?= X-BeenThere: iccrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussions of Internet Congestion Control Research Group \(ICCRG\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 22:36:24 -0000 --e89a8f839d51f5f8c604d84ebb8b Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Clearly, having a working AQM is a necessary prerequisite for ECN to be useful; one only overcome in the last year with CoDel/Pie. Variable bandwidth is still a challenge, but with CoDel at least, we think it can be done. And we've certainly implemented ECN support in the codel/fq_codel qdisc's (though would be grateful if ECN experts make sure it's been done correctly). The incentive structure needs to work here. There may be things we can and should do to provide incentive for ECN deployment. For Bell Heads working on wireless cellular transport, the incentive is really pretty clear: they ***hate*** dropping packets with a passion, not understanding that either packet drop or ECN are necessary, and it will probably be easier to convince them to adopt ECN than to drop packets. Given how hard they sweat to get packets over the air, I sort of understand where they come from. I believe some of the cellular carriers are requiring ECN support in handsets going forward, and as they classify VOIP into a separate bearer class anyway, I can see little incentive not to use ECN on their "best effort" bearer class. I believe all current operating systems react correctly to ECN marked packets; the only question is whether they will talk ECN if talked to (pretty common; Linux has done so now for quite a few years), *and* whether they enable ECN when establishing new connections or not (no one does right now by default). At the moment, Windows is vanishingly small fraction of handsets, being dominated by Android (Linux) and Apple as it is. I worry about bufferbloat in the HARQ layer of cellular networks not reflecting ECN marking into packets, but until that analysis has been done in real systems, it's just one more thing to worry about. Our Linux experience is that bufferbloat hides everywhere in current systems: the analogy in WiFi is the error correction layer in 802.11n, which causes large amounts of bloat, and fixing WiFi is very much a work in progress (except that not enough resources are currently available to go do the work, and it's more complicated that wired systems). Dave Taht cheered the first time he got the 802.11 layer to drop a packet, it was so much a problem. Right now, there are still some disincentives for ECN: e.g. some very small fraction of sites that become "black holes", or crashing antique middelboxes. We have no data on how much this is at this date, and the database that used to exist documenting middlebox problems has bit-rotted. These middleboxes are likely in the consumer edge, and unlikely to be in the path of most mobile devices and web sites on 3g/LTE. Mobile devices on home WiFi networks are more likely to have problems. We have ECN enabled in CeroWrt and have not noticed any problems; but 4-5 years ago OpenWrt (with a very much larger user base) still detected problems to the extent they had to disable initiating ECN connections. I know Bauer et. al. examined this a few years ago. But we have no data over the last several years I've seen (though this new paper referenced may: I've not had a chance to read it yet). There is one other issue with ECN: when operating at low bandwidth at the very edge of the net, it can still be advantageous to drop a packet rather than ECN mark it, to get back the transmission time of the packet. Dave Taht's experiments (IIRC) were below 4Mbps for this advantage (when doing VOIP over that bottleneck competing against other traffic in a best effort class). My intuition is to get VOIP reliable over WiFI on a busy network (or when far away from the AP) we'll want to classify the VOIP packets anyway and use the right hardware class in WiFi; this is primarily to get priority access to a transmit opportunity on WiFi rather than the previous reasons we've had. Certainly on other media we've seen little reason to have to do any explicit classification for VOIP anymore once running fq_codel. Things generally "just work" without all that hair for VOIP traffic. - Jim On Tue, Mar 19, 2013 at 5:49 PM, =CC=EC=C0=BD = wrote: > To let ECN be popular used =A3=ACthe most important is let the connection= which > used =A1=B0ECN=A1=B1 is fairness to the other connection; > So we should design new algorithm for ECN connection to "prize" those > people who use ECN; > > > hritian > > ________________________________________ > =B7=A2=BC=FE=C8=CB: Jim Gettys [jg@freedesktop.org] > =B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA3=D4=C220=C8=D5 1:26 > =B5=BD: Rick Jones > Cc: tcpm@ietf.org; aqm@ietf.org; iccrg@irtf.org; Mikael Abrahamsson > =D6=F7=CC=E2: Re: [iccrg] [tcpm] ECN support and usage on the Internet > > You need to distinguish 1) "Will talk ECN when talked to", from 2) "Will > initiate an ECN conversation". > > Linux, for example, will do 1) by default (and has for some time now), bu= t > requires configuration to turn on ECN when initiating a connection. > - Jim > > > > On Tue, Mar 19, 2013 at 10:45 AM, Rick Jones rick.jones2@hp.com>> wrote: > On 03/19/2013 02:22 AM, Mikael Abrahamsson wrote: > On Tue, 19 Mar 2013, Mirja K=A8=B9hlewind wrote: > > Do we need to start a campaign to further encourage greater ECN > support (also of network providers)? Asking the content providers on > the list(s): What are the reasons to not enable ECN support? > > Let me speculate: > > It's not on by default in Windows. There is little reason to turn it on, > because "nobody" acts on ECN, and nobody acts on ECN because there is no > demand for AQM, and even if there was AQM, it would most likely not be > ECN enabled. > > Out of curiosity, which stacks have ECN enabled by default? To my > recollection, on netperf.org I had to explicitly > enable TCP's use of ECN in the kernel which ships with Ubuntu 12.04. > > rick jones > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > > ________________________________ > > This email (including any attachments) is confidential and may be legally > privileged. If you received this email in error, please delete it > immediately and do not copy it or use it for any purpose or disclose its > contents to any other person. Thank you. > > > =B1=BE=B5=E7=D3=CA(=B0=FC=C0=A8=C8=CE=BA=CE=B8=BD=BC=FE)=BF=C9=C4=DC=BA= =AC=D3=D0=BB=FA=C3=DC=D7=CA=C1=CF=B2=A2=CA=DC=B7=A8=C2=C9=B1=A3=BB=A4=A1=A3= =C8=E7=C4=FA=B2=BB=CA=C7=D5=FD=C8=B7=B5=C4=CA=D5=BC=FE=C8=CB=A3=AC=C7=EB=C4= =FA=C1=A2=BC=B4=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A1=A3=C7=EB=B2=BB=D2=AA=BD=AB= =B1=BE=B5=E7=D3=CA=BD=F8=D0=D0=B8=B4=D6=C6=B2=A2=D3=C3=D7=F7=C8=CE=BA=CE=C6= =E4=CB=FB=D3=C3=CD=BE=A1=A2=BB=F2=CD=B8=C2=B6=B1=BE=D3=CA=BC=FE=D6=AE=C4=DA= =C8=DD=A1=A3=D0=BB=D0=BB=A1=A3 > --e89a8f839d51f5f8c604d84ebb8b Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable

Clearly, having a working AQM is a necessary prerequisite = for ECN to be useful; one only overcome in the last year with CoDel/Pie. &n= bsp;Variable bandwidth is still a challenge, but with CoDel at least, we th= ink it can be done. And we've certainly implemented ECN support i= n the codel/fq_codel qdisc's (though would be grateful if ECN experts m= ake sure it's been done correctly).

The incentive structure needs to work here. There may be thi= ngs we can and should do to provide incentive for ECN deployment.

For Bell Heads working on wireless cellular transport, the = incentive is really pretty clear: they ***hate*** dropping packets with a p= assion, not understanding that either packet drop or ECN are necessary, and= it will probably be easier to convince them to adopt ECN than to drop pack= ets. Given how hard they sweat to get packets over the air, I sort of= understand where they come from.

I believe some of the cellular carriers are requiring E= CN support in handsets going forward, and as they classify VOIP into a sepa= rate bearer class anyway, I can see little incentive not to use ECN on thei= r "best effort" bearer class.

I believe all current operating systems react cor= rectly to ECN marked packets; the only question is whether they will talk E= CN if talked to (pretty common; Linux has done so now for quite a few years= ), *and* whether they enable ECN when establishing new connections or not (= no one does right now by default).

At the moment, Windows is vanishingly small fract= ion of handsets, being dominated by Android (Linux) and Apple as it is.

I worry about bufferbloat in the HARQ layer of cellul= ar networks not reflecting ECN marking into packets, but until that analysi= s has been done in real systems, it's just one more thing to worry abou= t. Our Linux experience is that bufferbloat hides everywhere in current sys= tems: the analogy in WiFi is the error correction layer in 802.11n, which c= auses large amounts of bloat, and fixing WiFi is very much a work in progre= ss (except that not enough resources are currently available to go do the w= ork, and it's more complicated that wired systems). Dave Taht che= ered the first time he got the 802.11 layer to drop a packet, it was so muc= h a problem.

Right now, there are still some disincentive= s for ECN: e.g. some very small fraction of sites that become "black h= oles", or crashing antique middelboxes. We have no data on how much th= is is at this date, and the database that used to exist documenting middleb= ox problems has bit-rotted. These middleboxes are likely in the= consumer edge, and unlikely to be in the path of most mobile devices and w= eb sites on 3g/LTE. Mobile devices on home WiFi networks are more lik= ely to have problems.

We have ECN enabled in CeroWrt and have not= noticed any problems; but 4-5 years ago OpenWrt (with a very much larger u= ser base) still detected problems to the extent they had to disable initiat= ing ECN connections.

I know Bauer et. al. examined this a few ye= ars ago. But we have no data over the last several years I've seen (tho= ugh this new paper referenced may: I've not had a chance to read it yet= ).

There is one other issue with ECN: when ope= rating at low bandwidth at the very edge of the net, it can still be advant= ageous to drop a packet rather than ECN mark it, to get back the transmissi= on time of the packet. Dave Taht's experiments (IIRC) were below = 4Mbps for this advantage (when doing VOIP over that bottleneck competing ag= ainst other traffic in a best effort class).

My intuition is to get VOIP reliable over W= iFI on a busy network (or when far away from the AP) we'll want to clas= sify the VOIP packets anyway and use the right hardware class in WiFi; this= is primarily to get priority access to a transmit opportunity on WiFi rath= er than the previous reasons we've had. Certainly on other media = we've seen little reason to have to do any explicit classification for = VOIP anymore once running fq_codel. Things generally "just work&= quot; without all that hair for VOIP traffic.

&= nbsp; = - Jim

<= br>

On Tue, Mar 19, 2013 at 5:49 PM, =CC=EC= =C0=BD <tianlan.lhh@alibaba-inc.com> wrote:

To let ECN be popular used =A3=ACthe most im= portant is let the connection which used “ECN” is fairness to t= he other connection;
So we should design new algorithm for ECN connection to "prize" t= hose people who use ECN;

= ; &nb= sp; &= nbsp; = &nbs= p; hritian

________________________________________
=B7=A2=BC=FE=C8=CB: Jim Gettys [jg@fr= eedesktop.org]
=B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA3=D4=C220=C8=D5 1:26
=B5=BD: Rick Jones
Cc: tcpm@ietf.org; aqm@ietf.org; iccrg@irtf= .org; Mikael Abrahamsson
=D6=F7=CC=E2: Re: [iccrg] [tcpm] ECN support and usage on the Internet

You need to distinguish 1) "Will talk ECN when talked to", from 2= ) "Will initiate an ECN conversation".

Linux, for example, will do 1) by default (and has for some time now), but = requires configuration to turn on ECN when initiating a connection.
= ; - Jim

On Tue, Mar 19, 2013 at 10:45 AM, Rick Jones <rick.jones2@hp.com<mailto:rick.jones2@hp.com>> wrote:
On 03/19/2013 02:22 AM, Mikael Abrahamsson wrote:
On Tue, 19 Mar 2013, Mirja K=A8=B9hlewind wrote:

Do we need to start a campaign to further encourage greater ECN
support (also of network providers)? Asking the content providers on
the list(s): What are the reasons to not enable ECN support?

Let me speculate:

It's not on by default in Windows. There is little reason to turn it on= ,
because "nobody" acts on ECN, and nobody acts on ECN because ther= e is no
demand for AQM, and even if there was AQM, it would most likely not be
ECN enabled.

Out of curiosity, which stacks have ECN enabled by default? To = my recollection, on netper= f.org<http://netper= f.org> I had to explicitly enable TCP's use of ECN in the kernel= which ships with Ubuntu 12.04.

rick jones

_______________________________________________
tcpm mailing list

tcpm@ietf.org<mailto:tcpm@ietf.org>
ht= tps://www.ietf.org/mailman/listinfo/tcpm

________________________________

This email (including any attachments) is confidential and may be legally p= rivileged. If you received this email in error, please delete it immediatel= y and do not copy it or use it for any purpose or disclose its contents to = any other person. Thank you.

=B1=BE=B5=E7=D3=CA(=B0=FC=C0=A8=C8=CE=BA=CE=B8=BD=BC=FE)=BF=C9=C4=DC=BA=AC= =D3=D0=BB=FA=C3=DC=D7=CA=C1=CF=B2=A2=CA=DC=B7=A8=C2=C9=B1=A3=BB=A4=A1=A3=C8= =E7=C4=FA=B2=BB=CA=C7=D5=FD=C8=B7=B5=C4=CA=D5=BC=FE=C8=CB=A3=AC=C7=EB=C4=FA= =C1=A2=BC=B4=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A1=A3=C7=EB=B2=BB=D2=AA=BD=AB=B1= =BE=B5=E7=D3=CA=BD=F8=D0=D0=B8=B4=D6=C6=B2=A2=D3=C3=D7=F7=C8=CE=BA=CE=C6=E4= =CB=FB=D3=C3=CD=BE=A1=A2=BB=F2=CD=B8=C2=B6=B1=BE=D3=CA=BC=FE=D6=AE=C4=DA=C8= =DD=A1=A3=D0=BB=D0=BB=A1=A3

--e89a8f839d51f5f8c604d84ebb8b-- From gdt@gdt.id.au Tue Mar 19 16:09:07 2013 Return-Path: X-Original-To: iccrg@ietfa.amsl.com Delivered-To: iccrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C096621F867D; Tue, 19 Mar 2013 16:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001] 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 B+g11tgLWAzB; Tue, 19 Mar 2013 16:09:07 -0700 (PDT) Received: from aix.gdt.id.au (eth6445.sa.adsl.internode.on.net [150.101.30.44]) by ietfa.amsl.com (Postfix) with ESMTP id ABF0321F84D9; Tue, 19 Mar 2013 16:09:06 -0700 (PDT) Received: from thrace.44ansell.gdt.id.au (thrace.44ansell.gdt.id.au [192.168.253.149]) (authenticated bits=0) by aix.gdt.id.au (8.14.2/8.14.2) with ESMTP id r2JN8baD026631 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Mar 2013 09:38:38 +1030 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_D3CEF40D-2524-4B60-9F81-2151B0CC81D6" From: Glen Turner In-Reply-To: Date: Wed, 20 Mar 2013 09:38:37 +1030 Message-Id: References: <201303190904.32180.mkuehle@ikr.uni-stuttgart.de> <51487A27.7010904@hp.com>

To: Jim Gettys X-Mailer: Apple Mail (2.1283) Cc: Rick Jones , "iccrg@irtf.org" , "tcpm@ietf.org" , =?utf-8?B?5aSp5r6c?= , "aqm@ietf.org" , Mikael Abrahamsson Subject: Re: [iccrg] [tcpm] ECN support and usage on the Internet X-BeenThere: iccrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussions of Internet Congestion Control Research Group \(ICCRG\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 23:09:07 -0000 --Apple-Mail=_D3CEF40D-2524-4B60-9F81-2151B0CC81D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=GB2312 On 20/03/2013, at 9:06 AM, Jim Gettys wrote: >=20 > We have ECN enabled in CeroWrt and have not noticed any problems; but = 4-5 years ago OpenWrt (with a very much larger user base) still detected = problems to the extent they had to disable initiating ECN connections. =20= The issues with accessing web sites from ECN-using hosts were primarily = due to one software bug in one popular network vendor's popular = firewall. The software versions with that bug have been end-of-lifed by = the vendor. So you should have a much better experience with ECN = reachability these days. -glen= --Apple-Mail=_D3CEF40D-2524-4B60-9F81-2151B0CC81D6 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=GB2312

On 20/03/2013, at 9:06 AM, Jim Gettys wrote:

We have ECN enabled in CeroWrt and have not noticed any problems; but 4-5 years ago OpenWrt (with a very much larger user base) still detected problems to the extent they had to disable initiating ECN connections.

The issues with accessing web sites from ECN-using hosts were primarily due to one software bug in one popular network vendor's popular firewall. The software versions with that bug have been end-of-lifed by the vendor. So you should have a much better experience with ECN reachability these days.

-glen

--Apple-Mail=_D3CEF40D-2524-4B60-9F81-2151B0CC81D6-- From simon@superduper.net Tue Mar 19 16:43:27 2013 Return-Path: X-Original-To: iccrg@ietfa.amsl.com Delivered-To: iccrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE7B21F8D46; Tue, 19 Mar 2013 16:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152, SARE_SUB_OBFU_Q1=0.227] 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 DVWy6nOSy+zV; Tue, 19 Mar 2013 16:43:26 -0700 (PDT) Received: from masada.superduper.net (masada.superduper.net [85.119.82.91]) by ietfa.amsl.com (Postfix) with ESMTP id D48B721F8C5D; Tue, 19 Mar 2013 16:43:25 -0700 (PDT) Received: from snappy-wlan.parc.xerox.com ([13.1.108.21]) by masada.superduper.net with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UI6BX-0003Pr-9e; Tue, 19 Mar 2013 23:43:18 +0000 Message-ID: <5148F80F.5000401@superduper.net> Date: Tue, 19 Mar 2013 16:43:11 -0700 From: Simon Barber User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Jim Gettys References: <201303190904.32180.mkuehle@ikr.uni-stuttgart.de> <51487A27.7010904@hp.com>

In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Rick Jones , "iccrg@irtf.org" , "tcpm@ietf.org" , =?UTF-8?B?5aSp5r6c?= , "aqm@ietf.org" , Mikael Abrahamsson Subject: Re: [iccrg] =?utf-8?b?W2FxbV0g562U5aSNOiAgW3RjcG1dIEVDTiBzdXBwb3J0?= =?utf-8?q?_and_usage_on_the_Internet?= X-BeenThere: iccrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussions of Internet Congestion Control Research Group \(ICCRG\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 23:43:27 -0000 I'm not sure why people are so obsessed with ECN - the little data I've seen about it showed that it's effect on system throughput was in the noise. Sure, wireless guys don't like to waste precious wireless bandwidth, but they're not dropping packets that have used up the precious wireless bandwidth. They get dropped before the wireless link. Simon On 03/19/2013 03:36 PM, Jim Gettys wrote: > Clearly, having a working AQM is a necessary prerequisite for ECN to be > useful; one only overcome in the last year with CoDel/Pie. Variable > bandwidth is still a challenge, but with CoDel at least, we think it can > be done. And we've certainly implemented ECN support in the > codel/fq_codel qdisc's (though would be grateful if ECN experts make > sure it's been done correctly). > > The incentive structure needs to work here. There may be things we can > and should do to provide incentive for ECN deployment. > > For Bell Heads working on wireless cellular transport, the incentive is > really pretty clear: they ***hate*** dropping packets with a passion, > not understanding that either packet drop or ECN are necessary, and it > will probably be easier to convince them to adopt ECN than to drop > packets. Given how hard they sweat to get packets over the air, I sort > of understand where they come from. > > I believe some of the cellular carriers are requiring ECN support in > handsets going forward, and as they classify VOIP into a separate bearer > class anyway, I can see little incentive not to use ECN on their "best > effort" bearer class. > > I believe all current operating systems react correctly to ECN marked > packets; the only question is whether they will talk ECN if talked to > (pretty common; Linux has done so now for quite a few years), *and* > whether they enable ECN when establishing new connections or not (no one > does right now by default). > > At the moment, Windows is vanishingly small fraction of handsets, being > dominated by Android (Linux) and Apple as it is. > > I worry about bufferbloat in the HARQ layer of cellular networks not > reflecting ECN marking into packets, but until that analysis has been > done in real systems, it's just one more thing to worry about. Our Linux > experience is that bufferbloat hides everywhere in current systems: the > analogy in WiFi is the error correction layer in 802.11n, which causes > large amounts of bloat, and fixing WiFi is very much a work in progress > (except that not enough resources are currently available to go do the > work, and it's more complicated that wired systems). Dave Taht cheered > the first time he got the 802.11 layer to drop a packet, it was so much > a problem. > > Right now, there are still some disincentives for ECN: e.g. some very > small fraction of sites that become "black holes", or crashing antique > middelboxes. We have no data on how much this is at this date, and the > database that used to exist documenting middlebox problems has > bit-rotted. These middleboxes are likely in the consumer edge, and > unlikely to be in the path of most mobile devices and web sites on > 3g/LTE. Mobile devices on home WiFi networks are more likely to have > problems. > > We have ECN enabled in CeroWrt and have not noticed any problems; but > 4-5 years ago OpenWrt (with a very much larger user base) still detected > problems to the extent they had to disable initiating ECN connections. > > I know Bauer et. al. examined this a few years ago. But we have no data > over the last several years I've seen (though this new paper referenced > may: I've not had a chance to read it yet). > > There is one other issue with ECN: when operating at low bandwidth at > the very edge of the net, it can still be advantageous to drop a packet > rather than ECN mark it, to get back the transmission time of the > packet. Dave Taht's experiments (IIRC) were below 4Mbps for this > advantage (when doing VOIP over that bottleneck competing against other > traffic in a best effort class). > > My intuition is to get VOIP reliable over WiFI on a busy network (or > when far away from the AP) we'll want to classify the VOIP packets > anyway and use the right hardware class in WiFi; this is primarily to > get priority access to a transmit opportunity on WiFi rather than the > previous reasons we've had. Certainly on other media we've seen little > reason to have to do any explicit classification for VOIP anymore once > running fq_codel. Things generally "just work" without all that hair > for VOIP traffic. > - Jim > > > > > > On Tue, Mar 19, 2013 at 5:49 PM, 天澜

> wrote: > > To let ECN be popular used ，the most important is let the > connection which used “ECN” is fairness to the other connection; > So we should design new algorithm for ECN connection to "prize" > those people who use ECN; > > > hritian > > ________________________________________ > 发件人: Jim Gettys [jg@freedesktop.org ] > 发送时间: 2013年3月20日 1:26 > 到: Rick Jones > Cc: tcpm@ietf.org ; aqm@ietf.org > ; iccrg@irtf.org ; > Mikael Abrahamsson > 主题: Re: [iccrg] [tcpm] ECN support and usage on the Internet > > You need to distinguish 1) "Will talk ECN when talked to", from 2) > "Will initiate an ECN conversation". > > Linux, for example, will do 1) by default (and has for some time > now), but requires configuration to turn on ECN when initiating a > connection. > - Jim > > > > On Tue, Mar 19, 2013 at 10:45 AM, Rick Jones >> wrote: > On 03/19/2013 02:22 AM, Mikael Abrahamsson wrote: > On Tue, 19 Mar 2013, Mirja Kühlewind wrote: > > Do we need to start a campaign to further encourage greater ECN > support (also of network providers)? Asking the content providers on > the list(s): What are the reasons to not enable ECN support? > > Let me speculate: > > It's not on by default in Windows. There is little reason to turn it on, > because "nobody" acts on ECN, and nobody acts on ECN because there is no > demand for AQM, and even if there was AQM, it would most likely not be > ECN enabled. > > Out of curiosity, which stacks have ECN enabled by default? To my > recollection, on netperf.org > I had to explicitly enable > TCP's use of ECN in the kernel which ships with Ubuntu 12.04. > > rick jones > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > > ________________________________ > > This email (including any attachments) is confidential and may be > legally privileged. If you received this email in error, please > delete it immediately and do not copy it or use it for any purpose > or disclose its contents to any other person. Thank you. > > 本电邮(包括任何附件)可能含有机密资料并受法律保护。如您不是正确的收件 > 人，请您立即删除本邮件。请不要将本电邮进行复制并用作任何其他用途、或 > 透露本邮件之内容。谢谢。 > > > > > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm > From swmike@swm.pp.se Tue Mar 19 21:01:25 2013 Return-Path: X-Original-To: iccrg@ietfa.amsl.com Delivered-To: iccrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5A121F8F28 for ; Tue, 19 Mar 2013 21:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.105 X-Spam-Level: X-Spam-Status: No, score=-0.105 tagged_above=-999 required=5 tests=[AWL=-2.351, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_GB2312=1.345] 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 COI7-bw+33yl for ; Tue, 19 Mar 2013 21:01:24 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id A746121F8EF2 for ; Tue, 19 Mar 2013 21:01:24 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id A878A9C; Wed, 20 Mar 2013 05:01:22 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id A37A79A; Wed, 20 Mar 2013 05:01:22 +0100 (CET) Date: Wed, 20 Mar 2013 05:01:22 +0100 (CET) From: Mikael Abrahamsson To: Jim Gettys In-Reply-To: Message-ID: References: <201303190904.32180.mkuehle@ikr.uni-stuttgart.de> <51487A27.7010904@hp.com>

User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "tcpm@ietf.org" , "aqm@ietf.org" , "iccrg@irtf.org" Subject: Re: [iccrg] =?gb2312?b?tPC4tDogIFt0Y3BtXSBFQ04gc3VwcG9ydCBhbmQgdXNh?= =?gb2312?b?Z2Ugb24gdGhlIEludGVybmV0?= X-BeenThere: iccrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussions of Internet Congestion Control Research Group \(ICCRG\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 04:01:25 -0000 On Tue, 19 Mar 2013, Jim Gettys wrote: > I worry about bufferbloat in the HARQ layer of cellular networks not This might be from just one vendor, but the Radio Link Control (RLC) layer on our equipment will buffer up to 400 packets before it does tail-drop. There might be additional buffering in GGSN/SGSN doing rate-shaping before it's even sent to the RNC (which terminates the RLC layer between the RNC and the end user terminal equipment). All this buffering is strict FIFO. I personally belive that AQM at each of these buffering points would be beneficial to the end user equipment. > My intuition is to get VOIP reliable over WiFI on a busy network (or > when far away from the AP) we'll want to classify the VOIP packets > anyway and use the right hardware class in WiFi; this is primarily to > get priority access to a transmit opportunity on WiFi rather than the > previous reasons we've had. Certainly on other media we've seen little > reason to have to do any explicit classification for VOIP anymore once > running fq_codel. Things generally "just work" without all that hair > for VOIP traffic. I agree, fq_codel probably needs some DSCP handling so that VOIP packets (EF marked) would end up in a different hardware queue. For mobile, the bearer model would mean there would be an L4 inspection engine putting the traffic into the correct bearer anyway (that's the 3GPP way), so here codel probably wouldn't need to do anything (because there would be several codel instances running, one per bearer). -- Mikael Abrahamsson email: swmike@swm.pp.se From emmanuel.lochin@isae.fr Wed Mar 20 04:21:52 2013 Return-Path: X-Original-To: iccrg@ietfa.amsl.com Delivered-To: iccrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 198A821F8C93 for ; Wed, 20 Mar 2013 04:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 o1qz2nh6aCAU for ; Wed, 20 Mar 2013 04:21:51 -0700 (PDT) Received: from smtpext.isae.fr (smtpext.isae.fr [193.54.120.4]) by ietfa.amsl.com (Postfix) with SMTP id 3A49321F8C82 for ; Wed, 20 Mar 2013 04:21:51 -0700 (PDT) Received: from catalpa (unknown [10.4.1.11]) by smtpext.isae.fr (Postfix) with SMTP id C491D22E93C; Wed, 20 Mar 2013 12:21:45 +0100 (CET) Received: from [10.33.1.1] (pc-lochin.isae.fr [10.33.1.1]) by catalpa (Postfix) with ESMTP id 80197B7D6C; Wed, 20 Mar 2013 12:21:49 +0100 (CET) Message-ID: <51499BFB.7050202@isae.fr> Date: Wed, 20 Mar 2013 12:22:35 +0100 From: Emmanuel Lochin User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Yuchung Cheng References: <201303190904.32180.mkuehle@ikr.uni-stuttgart.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: "tcpm@ietf.org Extensions" , =?ISO-8859-1?Q?Mirja_K=FChlewind?= , aqm@ietf.org, iccrg@irtf.org Subject: Re: [iccrg] [tcpm] ECN support and usage on the Internet X-BeenThere: iccrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussions of Internet Congestion Control Research Group \(ICCRG\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 11:21:52 -0000 On 19/03/2013 21:17, Yuchung Cheng wrote: > Do people on the list know any (good) evaluation of performance impact > of ECN on real and/or emulated networks. E.g., how much faster will > the Web be if ECN is used (correctly). There is : http://dl.acm.org/citation.cfm?id=3D1080091.1080100 EL --=20 Emmanuel Lochin Professeur ISAE - OSSI Institut Sup=E9rieur de l'A=E9ronautique et de l'Espace (ISAE) Issu du rapprochement SUPAERO et ENSICA 10 avenue Edouard Belin - BP 54032 - 31055 Toulouse cedex 4 Tel : 05 61 33 91 85 - Fax : 05 61 33 91 88 Web : http://personnel.isae.fr/emmanuel-lochin/ --- "This email and any attachments are confidential. They may contain legall= y privileged information or copyright material. You should not read, copy= , use or disclose them without authorisation. If you are not an intended = recipient, please contact us at once by return email and then delete both= messages. We do not accept liability in connection with computer virus, = data corruption, delay, interruption, unauthorised access or unauthorised= amendment. This notice should not be removed" From rs@netapp.com Wed Mar 20 09:04:02 2013 Return-Path: X-Original-To: iccrg@ietfa.amsl.com Delivered-To: iccrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB1FC21F8581 for ; Wed, 20 Mar 2013 09:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.335 X-Spam-Level: X-Spam-Status: No, score=-10.335 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 bJD2OrXBoEJY for ; Wed, 20 Mar 2013 09:04:01 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3D19121F852B for ; Wed, 20 Mar 2013 09:04:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,879,1355126400"; d="scan'208";a="32368327" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx12-out.netapp.com with ESMTP; 20 Mar 2013 09:04:00 -0700 Received: from vmwexceht01-prd.hq.netapp.com (vmwexceht01-prd.hq.netapp.com [10.106.76.239]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r2KG40d0012922; Wed, 20 Mar 2013 09:04:00 -0700 (PDT) Received: from VMWEXCEHT06-PRD.hq.netapp.com (10.106.77.104) by vmwexceht01-prd.hq.netapp.com (10.106.76.239) with Microsoft SMTP Server (TLS) id 14.2.342.3; Wed, 20 Mar 2013 09:03:59 -0700 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.222]) by vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) with mapi id 14.02.0342.003; Wed, 20 Mar 2013 09:03:59 -0700 From: "Scheffenegger, Richard" To: Emmanuel Lochin , Yuchung Cheng Thread-Topic: [tcpm] ECN support and usage on the Internet Thread-Index: AQHOJN7vLn8i1zQNs0aR6qujDYSanZiu5guA///XOCA= Date: Wed, 20 Mar 2013 16:03:59 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24AC06C0@SACEXCMBX02-PRD.hq.netapp.com> References: <201303190904.32180.mkuehle@ikr.uni-stuttgart.de> <51499BFB.7050202@isae.fr> In-Reply-To: <51499BFB.7050202@isae.fr> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.53] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org Extensions" , "aqm@ietf.org" , "iccrg@irtf.org" Subject: Re: [iccrg] [tcpm] ECN support and usage on the Internet X-BeenThere: iccrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussions of Internet Congestion Control Research Group \(ICCRG\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 16:04:03 -0000 Thanks! Which fortunately is already an experimental http://tools.ietf.org/html/rfc= 5562=20 But too little experience to follow up on that just yet; Last time I looked= , I believe it was the AIX 5.3 TCP stack would default to 5562, when ECN is= enabled - but ECN is off by default in that OS... But the findings in that paper don't compare Tail-Drop non-ECN with AQM/ECN= *, which is probably what you are after Yuchung? Put differently: With a large enough fraction of AQM deployment, a reasonab= le number of RTOs should be avoidable (less probability that the last segme= nt in a session is dropped); with the addition of ECN, even that loss shoul= d go away... Do you know what the CCDF for object load times would look like, if there w= ere virtually no RTOs anymore? Apparently, the incentive to avoid (costly) RTOs is too small to drive ECN = deployment, even though that should be something easy to achieve with ECN o= n TCP. Richard Scheffenegger > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > Emmanuel Lochin > Sent: Mittwoch, 20. M=E4rz 2013 12:23 > To: Yuchung Cheng > Cc: tcpm@ietf.org Extensions; aqm@ietf.org; iccrg@irtf.org > Subject: Re: [tcpm] ECN support and usage on the Internet >=20 > On 19/03/2013 21:17, Yuchung Cheng wrote: > > Do people on the list know any (good) evaluation of performance impact > > of ECN on real and/or emulated networks. E.g., how much faster will > > the Web be if ECN is used (correctly). >=20 > There is : http://dl.acm.org/citation.cfm?id=3D1080091.1080100 >=20 > EL >=20 > -- > Emmanuel Lochin > Professeur ISAE - OSSI > Institut Sup=E9rieur de l'A=E9ronautique et de l'Espace (ISAE) Issu du > rapprochement SUPAERO et ENSICA > 10 avenue Edouard Belin - BP 54032 - 31055 Toulouse cedex 4 Tel : 05 61 3= 3 > 91 85 - Fax : 05 61 33 91 88 Web : http://personnel.isae.fr/emmanuel- > lochin/ > --- > "This email and any attachments are confidential. They may contain legall= y > privileged information or copyright material. You should not read, copy, > use or disclose them without authorisation. If you are not an intended > recipient, please contact us at once by return email and then delete both > messages. We do not accept liability in connection with computer virus, > data corruption, delay, interruption, unauthorised access or unauthorised > amendment. This notice should not be removed" >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From rs@netapp.com Wed Mar 20 09:14:08 2013 Return-Path: X-Original-To: iccrg@ietfa.amsl.com Delivered-To: iccrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C85A21F841D for ; Wed, 20 Mar 2013 09:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.008 X-Spam-Level: X-Spam-Status: No, score=-10.008 tagged_above=-999 required=5 tests=[AWL=-0.088, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, SARE_SUB_ENC_UTF8=0.152, SARE_SUB_OBFU_Q1=0.227] 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 8lUcyBoe+7aS for ; Wed, 20 Mar 2013 09:14:07 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 70BB521F841C for ; Wed, 20 Mar 2013 09:14:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,879,1355126400"; d="scan'208";a="32372231" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 20 Mar 2013 09:14:05 -0700 Received: from vmwexceht05-prd.hq.netapp.com (vmwexceht05-prd.hq.netapp.com [10.106.77.35]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r2KGE4l3029309; Wed, 20 Mar 2013 09:14:04 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.222]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.02.0342.003; Wed, 20 Mar 2013 09:14:03 -0700 From: "Scheffenegger, Richard" To: Simon Barber , Jim Gettys Thread-Topic: =?utf-8?B?W2FxbV0g562U5aSNOiBbaWNjcmddIFt0Y3BtXSBFQ04gc3VwcG9ydCBhbmQg?= =?utf-8?Q?usage_on_the_Internet?= Thread-Index: AQHOJPuQ4YV4mgvTF0iHLgehV1ZAsZiuv+6Q Date: Wed, 20 Mar 2013 16:14:03 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24AC06F7@SACEXCMBX02-PRD.hq.netapp.com> References: <201303190904.32180.mkuehle@ikr.uni-stuttgart.de> <51487A27.7010904@hp.com>

<5148F80F.5000401@superduper.net> In-Reply-To: <5148F80F.5000401@superduper.net> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.53] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "tcpm@ietf.org" , Rick Jones , "iccrg@irtf.org" , =?utf-8?B?5aSp5r6c?= , "aqm@ietf.org" , Mikael Abrahamsson Subject: Re: [iccrg] =?utf-8?b?W2FxbV0g562U5aSNOiAgW3RjcG1dIEVDTiBzdXBwb3J0?= =?utf-8?q?_and_usage_on_the_Internet?= X-BeenThere: iccrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussions of Internet Congestion Control Research Group \(ICCRG\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 16:14:08 -0000 SGkgU2ltb24sDQoNCg0KRm9yIG9uZSwgdGhyb3VnaHB1dCBpcyB0aGUgb25lIG1ldHJpYywgdGhh dCBzaG91bGQgTk9UIGJlIGluZmx1ZW5jZWQgYnkgRUNOLCBhY3R1YWxseS4gU28gaWYgdGhhdCBp cyAiaW4gdGhlIG5vaXNlIiwgdGhhdCBpcyBhIHZlcnkgZ29vZCBzaWduOyANCg0KVGhlIG1vcmUg aW50ZXJlc3RpbmcgbWV0cmljcywgdGhhdCBhcmUgYWRkcmVzc2VkIHdpdGggRUNOIGFyZSBsYXRl bmN5ICgicGFnZSBsb2FkIHRpbWVzIikgYW5kIG5ldHdvcmsgZWZmaWNpZW5jeSAoZmV3ZXIgcGFj a2V0cyBhcmUgbmVlZGxlc3NseSBwcm9jZXNzZWQgaW4gaW5pdGlhbCBob3BzLCBqdXN0IHRvIGJl IGRyb3BwZWQgYnkgdGhlIHBlbnVsdGltYXRlIGhvcDsgdGhhdCBiYW5kd2lkdGggY2FuIGJlIGFs bG9jYXRlZCB0byBvdGhlciBmbG93cyBldGMpLg0KDQpPdGhlciBzY2hlbWVzIHRoYXQgcmVkdWNl IGxhdGVuY3kgdXN1YWxseSBkbyBzbyBieSB0cmFkaW5nIGEgZ29vZCBzaGFyZSBvZiBiYW5kd2lk dGguLi4gKGNyZWRpdCBhbGxvY2F0aW9uIHNjaGVtZSB1c2VkIGluIEZDLCBhbnlvbmU/KQ0KDQoN CkVDTiBoYXQgYSBodWdlIGlzc3VlIG9mIGRlcGxveWFiaWxpdHkgaXNzdWVzLCB0aGF0IGhhZCBu b3RoaW5nIHRvIGRvIHdpdGggdGhlIG1lY2hhbmlzbSBpdHNlbGYsIGJ1dCB3aXRoIG1pc2JlaGF2 aW5nIGVxdWlwbWVudCBvbiB0aGUgc2lnbmFsaW5nIC0gYW5kIHRoZSBpbnN0aXR1dGlvbmFsIG1l bW9yeSBzdGlsbCByZW1lbWJlcnMgdGhvc2UgYWxiZWl0IGFueSBuZXcgc2lnbmFsaW5nIHNjaGVt ZSBjb3VsZCBydW4gaW50byBzaW1pbGFyIGlzc3VlcyAoaW5kZXBlbmRlbnQgb2YgdGhlIG1lY2hh bmlzbXMpLg0KDQoNCkllLiBzb21lIHBlb3BsZSBzdGlsbCBoYXZlbid0IGdvdCB0aGUgTWVtbyB0 aGF0IElQdjQgVE9TIHdhcyBkZXByZWNhdGVkIHF1aXRlIHNvbWUgdGltZSBhZ28gKG5vdyBEaWZm U2Vydi9FQ04pLA0KDQpSZWdhcmRzLA0KDQpSaWNoYXJkIFNjaGVmZmVuZWdnZXINCg0KDQoNCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogYXFtLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzphcW0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+IFNpbW9uIEJhcmJl cg0KPiBTZW50OiBNaXR0d29jaCwgMjAuIE3DpHJ6IDIwMTMgMDA6NDMNCj4gVG86IEppbSBHZXR0 eXMNCj4gQ2M6IFJpY2sgSm9uZXM7IGljY3JnQGlydGYub3JnOyB0Y3BtQGlldGYub3JnOyDlpKnm vpw7IGFxbUBpZXRmLm9yZzsgTWlrYWVsDQo+IEFicmFoYW1zc29uDQo+IFN1YmplY3Q6IFJlOiBb YXFtXSDnrZTlpI06IFtpY2NyZ10gW3RjcG1dIEVDTiBzdXBwb3J0IGFuZCB1c2FnZSBvbiB0aGUN Cj4gSW50ZXJuZXQNCj4gDQo+IEknbSBub3Qgc3VyZSB3aHkgcGVvcGxlIGFyZSBzbyBvYnNlc3Nl ZCB3aXRoIEVDTiAtIHRoZSBsaXR0bGUgZGF0YSBJJ3ZlDQo+IHNlZW4gYWJvdXQgaXQgc2hvd2Vk IHRoYXQgaXQncyBlZmZlY3Qgb24gc3lzdGVtIHRocm91Z2hwdXQgd2FzIGluIHRoZQ0KPiBub2lz ZS4gU3VyZSwgd2lyZWxlc3MgZ3V5cyBkb24ndCBsaWtlIHRvIHdhc3RlIHByZWNpb3VzIHdpcmVs ZXNzDQo+IGJhbmR3aWR0aCwgYnV0IHRoZXkncmUgbm90IGRyb3BwaW5nIHBhY2tldHMgdGhhdCBo YXZlIHVzZWQgdXAgdGhlIHByZWNpb3VzDQo+IHdpcmVsZXNzIGJhbmR3aWR0aC4gVGhleSBnZXQg ZHJvcHBlZCBiZWZvcmUgdGhlIHdpcmVsZXNzIGxpbmsuDQo+IA0KPiBTaW1vbg0KPiANCg0K From rs@netapp.com Thu Mar 21 08:29:19 2013 Return-Path: X-Original-To: iccrg@ietfa.amsl.com Delivered-To: iccrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC8721F90DA for ; Thu, 21 Mar 2013 08:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.216 X-Spam-Level: X-Spam-Status: No, score=-10.216 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] 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 STKjKl3jXRYH for ; Thu, 21 Mar 2013 08:29:18 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 7211021F905B for ; Thu, 21 Mar 2013 08:29:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,887,1355126400"; d="scan'208";a="16004176" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 21 Mar 2013 08:29:18 -0700 Received: from vmwexceht01-prd.hq.netapp.com (exchsmtp.hq.netapp.com [10.106.76.239]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r2LFTHGr006912; Thu, 21 Mar 2013 08:29:17 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.222]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.02.0342.003; Thu, 21 Mar 2013 08:29:16 -0700 From: "Scheffenegger, Richard" To: =?utf-8?B?5aSp5r6c?= , Emmanuel Lochin , Yuchung Cheng Thread-Topic: [iccrg] [tcpm] ECN support and usage on the Internet Thread-Index: AQHOJN7vLn8i1zQNs0aR6qujDYSanZiu5guA///XOCCAAW4vAIAAGwOw Date: Thu, 21 Mar 2013 15:29:16 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24AC54A0@SACEXCMBX02-PRD.hq.netapp.com> References: <201303190904.32180.mkuehle@ikr.uni-stuttgart.de> <51499BFB.7050202@isae.fr>, <012C3117EDDB3C4781FD802A8C27DD4F24AC06C0@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.53] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "tcpm@ietf.org Extensions" , "aqm@ietf.org" , "iccrg@irtf.org" Subject: Re: [iccrg] [tcpm] ECN support and usage on the Internet X-BeenThere: iccrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussions of Internet Congestion Control Research Group \(ICCRG\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 15:29:19 -0000 SGksDQoNCkknbSBhZnJhaWQgSSB3YXMgbm90IGFibGUgdG8gcGFyc2UgeW91ciBzdGF0ZW1lbnQu DQoNCk15IGNvbW1lbnQgd2FzIG5vdCBhYm91dCByZWR1Y2luZyB0aGUgUlRPIHRpbWUgKCEpLiBP biB0aGUgY29udHJhcnksIEkgd2FzIHBvaW50aW5nIG91dCwgdGhhdCB3aXRoIEVDTiAoYW5kIHdp dGhvdXQgZ2VudWluZSBsb3NzIGR1ZSB0byBjb3JydXB0aW9uKSwgUlRPcyAtIHJlZ2FyZGxlc3Mg b2YgdGhlIGFjdHVhbCB0aW1lciB2YWx1ZSBhcyBsb25nIGFzIHRoYXQgaXMgcmVhc29uYWJseSBs YXJnZXIgdGhhbiBSVFQgLSBzaG91bGQgYmVjb21lIGV4Y2VlZGluZ2x5IHJhcmUsIG9uY2UgRUNO IGlzIGZ1bGx5IGRlcGxveWVkLg0KDQoNCk9uY2UgUlRPIGlzIG5vIGxvbmdlciBuZWNlc3Nhcnkg dG8gcmVjb3ZlciB+NzAlIG9mIGFsbCBsb3N0IFRDUCBzZWdtZW50cyAoZ29vZ2xlIHdlYnNlcnZl ciBkYXRhKSwgeW91IGNhbiBhY3R1YWxseSAqaW5jcmVhc2UqIHRoZSBtaW5pbXVtIFJUTyB0aW1l b3V0IHZhbHVlIHNpbmNlIGl0IHJlYWxseSBpcyBhIGxhc3QgcmVzb3J0LiAoVXNpbmcgYSAibGFz dCByZXNvcnQiIHJlY292ZXJ5IG1lY2hhbmlzbSBmb3IgNzAlIG9mIHJlY292ZXJpZXMgaXMgcmVh bGx5IE5PVCAibGFzdCByZXNvcnQiKS4NCg0KDQpCZXN0IHJlZ2FyZHMsDQoNClJpY2hhcmQgU2No ZWZmZW5lZ2dlcg0KDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiDl pKnmvpwgW21haWx0bzp0aWFubGFuLmxoaEBhbGliYWJhLWluYy5jb21dDQo+IFNlbnQ6IERvbm5l cnN0YWcsIDIxLiBNw6RyeiAyMDEzIDA3OjQ3DQo+IFRvOiBTY2hlZmZlbmVnZ2VyLCBSaWNoYXJk OyBFbW1hbnVlbCBMb2NoaW47IFl1Y2h1bmcgQ2hlbmcNCj4gQ2M6IHRjcG1AaWV0Zi5vcmcgRXh0 ZW5zaW9uczsgYXFtQGlldGYub3JnOyBpY2NyZ0BpcnRmLm9yZw0KPiBTdWJqZWN0OiDnrZTlpI06 IFtpY2NyZ10gW3RjcG1dIEVDTiBzdXBwb3J0IGFuZCB1c2FnZSBvbiB0aGUgSW50ZXJuZXQNCj4g DQo+IGFib3V0IFJUTyAsYWNjcm9kaW5nIHRvIG91dCBleHBlcmllbmNlICx1c2Ugc21hbGwgcHJv YmUgcGFja2V0IGF0IGxlYXN0DQo+IHJlZHVjZSA5MCUgUlRPIHRpbWXvvIhTaW5jZSAyMDEwLG5v dyBldmVyeSBkYXkgcGVlayBmbG9lIG1vcmUgdGhhbiAxVGJwcyDvvIkNCj4gOyBDb25zaWRlciB0 aGUgbW9iaWxlIG5ldHdvcmsgRXhjZXNzaXZlIHJlZHVjZSBSVE8gdGltZSBpcyB1bnJlYXNvbmFi bGU7DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IOWP keS7tuS6ujogU2NoZWZmZW5lZ2dlciwgUmljaGFyZCBbcnNAbmV0YXBwLmNvbV0NCj4g5Y+R6YCB 5pe26Ze0OiAyMDEz5bm0M+aciDIx5pelIDA6MDMNCj4g5YiwOiBFbW1hbnVlbCBMb2NoaW47IFl1 Y2h1bmcgQ2hlbmcNCj4gQ2M6IHRjcG1AaWV0Zi5vcmcgRXh0ZW5zaW9uczsgYXFtQGlldGYub3Jn OyBpY2NyZ0BpcnRmLm9yZw0KPiDkuLvpopg6IFJlOiBbaWNjcmddIFt0Y3BtXSBFQ04gc3VwcG9y dCBhbmQgdXNhZ2Ugb24gdGhlIEludGVybmV0DQo+IA0KPiBUaGFua3MhDQo+IA0KPiBXaGljaCBm b3J0dW5hdGVseSBpcyBhbHJlYWR5IGFuIGV4cGVyaW1lbnRhbA0KPiBodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9yZmM1NTYyDQo+IA0KPiBCdXQgdG9vIGxpdHRsZSBleHBlcmllbmNlIHRvIGZv bGxvdyB1cCBvbiB0aGF0IGp1c3QgeWV0OyBMYXN0IHRpbWUgSQ0KPiBsb29rZWQsIEkgYmVsaWV2 ZSBpdCB3YXMgdGhlIEFJWCA1LjMgVENQIHN0YWNrIHdvdWxkIGRlZmF1bHQgdG8gNTU2Miwgd2hl bg0KPiBFQ04gaXMgZW5hYmxlZCAtIGJ1dCBFQ04gaXMgb2ZmIGJ5IGRlZmF1bHQgaW4gdGhhdCBP Uy4uLg0KPiANCj4gDQo+IEJ1dCB0aGUgZmluZGluZ3MgaW4gdGhhdCBwYXBlciBkb24ndCBjb21w YXJlIFRhaWwtRHJvcCBub24tRUNOIHdpdGgNCj4gQVFNL0VDTiosIHdoaWNoIGlzIHByb2JhYmx5 IHdoYXQgeW91IGFyZSBhZnRlciBZdWNodW5nPw0KPiANCj4gDQo+IFB1dCBkaWZmZXJlbnRseTog V2l0aCBhIGxhcmdlIGVub3VnaCBmcmFjdGlvbiBvZiBBUU0gZGVwbG95bWVudCwgYQ0KPiByZWFz b25hYmxlIG51bWJlciBvZiBSVE9zIHNob3VsZCBiZSBhdm9pZGFibGUgKGxlc3MgcHJvYmFiaWxp dHkgdGhhdCB0aGUNCj4gbGFzdCBzZWdtZW50IGluIGEgc2Vzc2lvbiBpcyBkcm9wcGVkKTsgd2l0 aCB0aGUgYWRkaXRpb24gb2YgRUNOLCBldmVuIHRoYXQNCj4gbG9zcyBzaG91bGQgZ28gYXdheS4u Lg0KPiANCj4gDQo+IERvIHlvdSBrbm93IHdoYXQgdGhlIENDREYgZm9yIG9iamVjdCBsb2FkIHRp bWVzIHdvdWxkIGxvb2sgbGlrZSwgaWYgdGhlcmUNCj4gd2VyZSB2aXJ0dWFsbHkgbm8gUlRPcyBh bnltb3JlPw0KPiANCj4gDQo+IEFwcGFyZW50bHksIHRoZSBpbmNlbnRpdmUgdG8gYXZvaWQgKGNv c3RseSkgUlRPcyBpcyB0b28gc21hbGwgdG8gZHJpdmUgRUNODQo+IGRlcGxveW1lbnQsIGV2ZW4g dGhvdWdoIHRoYXQgc2hvdWxkIGJlIHNvbWV0aGluZyBlYXN5IHRvIGFjaGlldmUgd2l0aCBFQ04N Cj4gb24gVENQLg0KPiANCj4gDQo+IFJpY2hhcmQgU2NoZWZmZW5lZ2dlcg0KPiANCj4gDQo+IA0K PiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogdGNwbS1ib3VuY2VzQGll dGYub3JnIFttYWlsdG86dGNwbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4gPiBPZiBF bW1hbnVlbCBMb2NoaW4NCj4gPiBTZW50OiBNaXR0d29jaCwgMjAuIE3DpHJ6IDIwMTMgMTI6MjMN Cj4gPiBUbzogWXVjaHVuZyBDaGVuZw0KPiA+IENjOiB0Y3BtQGlldGYub3JnIEV4dGVuc2lvbnM7 IGFxbUBpZXRmLm9yZzsgaWNjcmdAaXJ0Zi5vcmcNCj4gPiBTdWJqZWN0OiBSZTogW3RjcG1dIEVD TiBzdXBwb3J0IGFuZCB1c2FnZSBvbiB0aGUgSW50ZXJuZXQNCj4gPg0KPiA+IE9uIDE5LzAzLzIw MTMgMjE6MTcsIFl1Y2h1bmcgQ2hlbmcgd3JvdGU6DQo+ID4gPiBEbyBwZW9wbGUgb24gdGhlIGxp c3Qga25vdyBhbnkgKGdvb2QpIGV2YWx1YXRpb24gb2YgcGVyZm9ybWFuY2UNCj4gPiA+IGltcGFj dCBvZiBFQ04gb24gcmVhbCBhbmQvb3IgZW11bGF0ZWQgbmV0d29ya3MuIEUuZy4sIGhvdyBtdWNo DQo+ID4gPiBmYXN0ZXIgd2lsbCB0aGUgV2ViIGJlIGlmIEVDTiBpcyB1c2VkIChjb3JyZWN0bHkp Lg0KPiA+DQo+ID4gVGhlcmUgaXMgOiBodHRwOi8vZGwuYWNtLm9yZy9jaXRhdGlvbi5jZm0/aWQ9 MTA4MDA5MS4xMDgwMTAwDQo+ID4NCj4gPiBFTA0KPiA+DQo+ID4gLS0NCj4gPiBFbW1hbnVlbCBM b2NoaW4NCj4gPiBQcm9mZXNzZXVyIElTQUUgLSBPU1NJDQo+ID4gSW5zdGl0dXQgU3Vww6lyaWV1 ciBkZSBsJ0HDqXJvbmF1dGlxdWUgZXQgZGUgbCdFc3BhY2UgKElTQUUpIElzc3UgZHUNCj4gPiBy YXBwcm9jaGVtZW50IFNVUEFFUk8gZXQgRU5TSUNBDQo+ID4gMTAgYXZlbnVlIEVkb3VhcmQgQmVs aW4gLSBCUCA1NDAzMiAtIDMxMDU1IFRvdWxvdXNlIGNlZGV4IDQgVGVsIDogMDUNCj4gPiA2MSAz Mw0KPiA+IDkxIDg1IC0gRmF4IDogMDUgNjEgMzMgOTEgODggV2ViIDogaHR0cDovL3BlcnNvbm5l bC5pc2FlLmZyL2VtbWFudWVsLQ0KPiA+IGxvY2hpbi8NCj4gPiAtLS0NCj4gPiAiVGhpcyBlbWFp bCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwuIFRoZXkgbWF5IGNvbnRhaW4N Cj4gPiBsZWdhbGx5IHByaXZpbGVnZWQgaW5mb3JtYXRpb24gb3IgY29weXJpZ2h0IG1hdGVyaWFs LiBZb3Ugc2hvdWxkIG5vdA0KPiA+IHJlYWQsIGNvcHksIHVzZSBvciBkaXNjbG9zZSB0aGVtIHdp dGhvdXQgYXV0aG9yaXNhdGlvbi4gSWYgeW91IGFyZSBub3QNCj4gPiBhbiBpbnRlbmRlZCByZWNp cGllbnQsIHBsZWFzZSBjb250YWN0IHVzIGF0IG9uY2UgYnkgcmV0dXJuIGVtYWlsIGFuZA0KPiA+ IHRoZW4gZGVsZXRlIGJvdGggbWVzc2FnZXMuIFdlIGRvIG5vdCBhY2NlcHQgbGlhYmlsaXR5IGlu IGNvbm5lY3Rpb24NCj4gPiB3aXRoIGNvbXB1dGVyIHZpcnVzLCBkYXRhIGNvcnJ1cHRpb24sIGRl bGF5LCBpbnRlcnJ1cHRpb24sDQo+ID4gdW5hdXRob3Jpc2VkIGFjY2VzcyBvciB1bmF1dGhvcmlz ZWQgYW1lbmRtZW50LiBUaGlzIG5vdGljZSBzaG91bGQgbm90IGJlDQo+IHJlbW92ZWQiDQo+ID4N Cj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ IHRjcG0gbWFpbGluZyBsaXN0DQo+ID4gdGNwbUBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vdGNwbQ0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IA0KPiBUaGlzIGVtYWlsIChpbmNsdWRpbmcgYW55IGF0dGFjaG1l bnRzKSBpcyBjb25maWRlbnRpYWwgYW5kIG1heSBiZSBsZWdhbGx5DQo+IHByaXZpbGVnZWQuIElm IHlvdSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0DQo+IGlt bWVkaWF0ZWx5IGFuZCBkbyBub3QgY29weSBpdCBvciB1c2UgaXQgZm9yIGFueSBwdXJwb3NlIG9y IGRpc2Nsb3NlIGl0cw0KPiBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLiBUaGFuayB5b3Uu DQo+IA0KPiDmnKznlLXpgq4o5YyF5ous5Lu75L2V6ZmE5Lu2KeWPr+iDveWQq+acieacuuWvhui1 hOaWmeW5tuWPl+azleW+i+S/neaKpOOAguWmguaCqOS4jeaYr+ato+ehrueahOaUtuS7tuS6uu+8 jOivt+aCqOeri+WNs+WIoOmZpA0KPiDmnKzpgq7ku7bjgILor7fkuI3opoHlsIbmnKznlLXpgq7o v5vooYzlpI3liLblubbnlKjkvZzku7vkvZXlhbbku5bnlKjpgJTjgIHmiJbpgI/pnLLmnKzpgq7k u7bkuYvlhoXlrrnjgILosKLosKLjgIINCg== From lars@netapp.com Thu Mar 21 10:06:01 2013 Return-Path: X-Original-To: iccrg@ietfa.amsl.com Delivered-To: iccrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B03EE21F914B for ; Thu, 21 Mar 2013 10:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.423 X-Spam-Level: X-Spam-Status: No, score=-10.423 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227] 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 KWMHF7ijPFj9 for ; Thu, 21 Mar 2013 10:06:01 -0700 (PDT) Received: from mx1.netapp.com (mx1.netapp.com [216.240.18.38]) by ietfa.amsl.com (Postfix) with ESMTP id 12CD021F90CC for ; Thu, 21 Mar 2013 10:05:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,887,1355126400"; d="scan'208";a="248078622" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx1-out.netapp.com with ESMTP; 21 Mar 2013 10:05:58 -0700 Received: from vmwexceht05-prd.hq.netapp.com (vmwexceht05-prd.hq.netapp.com [10.106.77.35]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r2LH5vLw001598; Thu, 21 Mar 2013 10:05:57 -0700 (PDT) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.218]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.02.0342.003; Thu, 21 Mar 2013 10:05:56 -0700 From: "Eggert, Lars" To: "end2end-interest@postel.org" , "iccrg@irtf.org" Thread-Topic: New Non-WG Mailing List: aqm -- Active Queue Management Thread-Index: AQHOJaMIhS9uhG8Br0+YPlnwSPZsxg== Date: Thu, 21 Mar 2013 17:05:56 +0000 Message-ID: References: <20130320194153.2133.60344.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.115] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [iccrg] Fwd: New Non-WG Mailing List: aqm -- Active Queue Management X-BeenThere: iccrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussions of Internet Congestion Control Research Group \(ICCRG\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 17:06:01 -0000 Potentially of interest. Begin forwarded message: > From: IETF Secretariat > Subject: New Non-WG Mailing List: aqm -- Active Queue Management > Date: March 20, 2013 12:41:53 PDT > To: IETF Announcement List > Cc: , Martin Stiemerling >=20 >=20 > A new IETF non-working group email list has been created. >=20 > List address: aqm@ietf.org > Archive: http://www.ietf.org/mail-archive/web/aqm/current/maillist.html > To subscribe: https://www.ietf.org/mailman/listinfo/aqm >=20 > Purpose: This list is for discussing requirements, recommendations, algor= ithms, evaluation techniques, and other topics related to active queue > management algorithms and methods for protecting flows from one > another at a bottleneck. >=20 > For additional information, please contact the list administrators. >=20 From mirja.kuehlewind@ikr.uni-stuttgart.de Fri Mar 29 04:04:07 2013 Return-Path: X-Original-To: iccrg@ietfa.amsl.com Delivered-To: iccrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAA921F92D5 for ; Fri, 29 Mar 2013 04:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.956 X-Spam-Level: X-Spam-Status: No, score=-1.956 tagged_above=-999 required=5 tests=[AWL=0.293, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 DOH88K1cGaAJ for ; Fri, 29 Mar 2013 04:04:05 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id ADBA621F92D4 for ; Fri, 29 Mar 2013 04:04:01 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id AD96A602F3 for ; Fri, 29 Mar 2013 12:03:59 +0100 (CET) Received: from vpn-2-cl195 (vpn-2-cl195 [10.41.21.195]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 94C37602F2 for ; Fri, 29 Mar 2013 12:03:59 +0100 (CET) Content-Disposition: inline From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: iccrg@irtf.org Date: Fri, 29 Mar 2013 12:03:59 +0100 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201303291203.59412.mirja.kuehlewind@ikr.uni-stuttgart.de> Subject: [iccrg] [CSWS'13] CfP X-BeenThere: iccrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussions of Internet Congestion Control Research Group \(ICCRG\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 11:04:07 -0000 Hi, we are organizing a Capacity Sharing Workshop (CSWS'13) colocated with ICNP= '13=20 in G=F6ttingen, Germany, in October.=20 =46ind below the CfP including the link to our webpage. Please also help=20 distributing the CfP to those people who might be interested. Thanks and Happy Easter! Dirk & Mirja =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0CALL FOR PAPERS =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0----------------------------------- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Capacity Sharing Workshop (CSWS'13) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0----------------------------------- In conjunction with ICNP'13, 7-11 October, Goettingen, Germany. Internet data traffic continues to grow rapidly. The challenge that operato= rs=20 face, especially in the mobile Internet, is to support more subscribers wit= h=20 higher bandwidth demands and a large variety of services with different=20 requirements. Therefore, operators need to seek for new technologies to=20 efficiently utilize the available network resources, in particular, this=20 concerns resource allocation and flow management. At the same time, network= =20 virtualization in data centers and carrier networks enables a more flexible= =20 and efficient resource management - but creates new challenges for sharing= =20 capacity among tenants and users of those networks, e.g, scaling up network= =20 resources transparently based on the congestion level. In wireless networks= ,=20 capacity sharing is particularly relevant due to the inherently limited=20 resources, which render a simple "throwing bandwidth at the problem" soluti= on=20 impossible. This change in network operation and the strong growth and continual change= s=20 in the traffic characteristics and usage behavior raises questions on how t= o=20 share limited capacity resources fairly and more efficiently. While=20 efficiency is most important when resources are spare, fairness need to be= =20 evaluated based on the different quality requirements of the various Intern= et=20 services that we have today. While the Internet, especially the mobile=20 Internet, was mostly engineered to provide a low loss service, low-latency= =20 services are not well supported today. In addition, there is regulation tha= t=20 can impose additional requirements in some markets, such as availability=20 requirements, network neutrality etc. The objective of this workshop is to bring together researchers in the area= of=20 transport protocols, system designers of data centers, fixed and mobile=20 access networks, and their applications to advance the state of research on= =20 capacity sharing. We solicit contributions on the state-of-the-art, results= =20 of ongoing research, open issues, trends and new ideas. We solicit=20 contributions on the state-of-the-art, results of ongoing research, open=20 issues, trends and new ideas. We want to encourage researchers to consider= =20 integrated consideration of the problem space over all layers.=20 Topics =2D----- Topics of particular interest include, but are not limited to * Context-aware resource allocation and cross-layer adaptation * Network protocols to exchange information on the network state * Support low-latency services and Transport layer solutions * Possible interactions with cellular/fixed access networks * Application-layer adaption especially for mobile and interactive services * Network Function Virtualization and SDN to implement capacity sharing * QoE and fairness definitions, metrics and evaluation * Data traffic characteristics in fixed and mobile Internet * Economic aspects on capacity sharing and business models * Related standardization activities, projects and regulatory constraints Submission =2D--------- Submissions must be original, unpublished work, and not under consideration= at=20 another conference or journal. Submitted papers must be at most six (6) pag= es=20 long, including all figures, tables, references, and appendices in IEEE=20 Computer Society format. Please see the workshop webpage for further submission guidelines: http://icnp13.informatik.uni-goettingen.de/csws13/ Important Dates =2D--------------- Paper submission deadline: June 1, 2013 Acceptance notification: August 2, 2013 Camera-ready paper: August 9, 2013 Workshop date: October, 2013 (to be announced) Workshop Co-Chairs =2D----------------- Mirja K=FChlewind, IKR University of Stuttgart, Germany Dirk Kutscher, NEC Europe Labs Heidelberg, Germany =2D------------------------------------------------------ =2D-=20 =2D------------------------------------------------------------------ Dipl.-Ing. Mirja K=FChlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de =2D------------------------------------------------------------------ =2D------------------------------------------------------ =2D-=20 =2D------------------------------------------------------------------ Dipl.-Ing. Mirja K=FChlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de =2D------------------------------------------------------------------