From internet-drafts@ietf.org Mon Jul 9 15:13:29 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71F3B21F868A; Mon, 9 Jul 2012 15:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, 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 mmRr6F0rILrQ; Mon, 9 Jul 2012 15:13:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0817A21F8686; Mon, 9 Jul 2012 15:13:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120709221327.14787.62968.idtracker@ietfa.amsl.com> Date: Mon, 09 Jul 2012 15:13:27 -0700 Cc: conex@ietf.org Subject: [conex] I-D Action: draft-ietf-conex-mobile-00.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 22:13:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Congestion Exposure Working Group of the = IETF. Title : Mobile Communication Congestion Exposure Scenario Author(s) : Dirk Kutscher Faisal Ghias Mir Rolf Winter Suresh Krishnan Ying Zhang Carlos J. Bernardos Filename : draft-ietf-conex-mobile-00.txt Pages : 23 Date : 2012-07-09 Abstract: This memo describes a mobile communications use case for congestion exposure (CONEX) with a particular focus on mobile communication networks such as 3GPP Evoled Packet System (EPS). The draft provides a brief overview of the architecture of these networks (both access and core networks), current QoS mechanisms and then discusses how congestion exposure concepts could be applied. Based on this, this memo suggests a set of requirements for CONEX mechanisms that particularly apply to mobile networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-conex-mobile There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-conex-mobile-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Jul 16 15:28:35 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0D7A11E82F8; Mon, 16 Jul 2012 15:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.519 X-Spam-Level: X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, 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 VVzqykAwAzVg; Mon, 16 Jul 2012 15:28:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C268221F886E; Mon, 16 Jul 2012 15:28:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120716222833.23980.83038.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2012 15:28:33 -0700 Cc: conex@ietf.org Subject: [conex] I-D Action: draft-ietf-conex-concepts-uses-05.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 22:28:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Congestion Exposure Working Group of the = IETF. Title : ConEx Concepts and Use Cases Author(s) : Bob Briscoe Richard Woundy Alissa Cooper Filename : draft-ietf-conex-concepts-uses-05.txt Pages : 18 Date : 2012-07-16 Abstract: This document provides the entry point to the set of documentation about the Congestion Exposure (ConEx) protocol. It explains the motivation for including a ConEx marking at the IP layer: to expose information about congestion to network nodes. Although such information may have a number of uses, this document focuses on how the information communicated by the ConEx marking can serve as the basis for significantly more efficient and effective traffic management than what exists on the Internet today. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-conex-concepts-uses There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-conex-concepts-uses-05 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-conex-concepts-uses-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Jul 16 15:51:05 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B671811E813D; Mon, 16 Jul 2012 15:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.518 X-Spam-Level: X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, 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 7osAiehfRdAs; Mon, 16 Jul 2012 15:51:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 177F911E8079; Mon, 16 Jul 2012 15:51:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120716225105.14155.40653.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2012 15:51:05 -0700 Cc: conex@ietf.org Subject: [conex] I-D Action: draft-ietf-conex-abstract-mech-05.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 22:51:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Congestion Exposure Working Group of the = IETF. Title : Congestion Exposure (ConEx) Concepts and Abstract Mechan= ism Author(s) : Matt Mathis Bob Briscoe Filename : draft-ietf-conex-abstract-mech-05.txt Pages : 27 Date : 2012-07-16 Abstract: This document describes an abstract mechanism by which senders inform the network about the congestion encountered by packets earlier in the same flow. Today, network elements at any layer may signal congestion to the receiver by dropping packets or by ECN markings, and the receiver passes this information back to the sender in transport-layer feedback. The mechanism described here enables the sender to also relay this congestion information back into the network in-band at the IP layer, such that the total amount of congestion from all elements on the path is revealed to all IP elements along the path, where it could, for example, be used to provide input to traffic management. This mechanism is called congestion exposure or ConEx. The companion document "ConEx Concepts and Use Cases" provides the entry-point to the set of ConEx documentation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-conex-abstract-mech There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-conex-abstract-mech-05 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-conex-abstract-mech-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nanditad@google.com Mon Jul 16 18:21:04 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F4021F87FF for ; Mon, 16 Jul 2012 18:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 RjoUBPu41XxC for ; Mon, 16 Jul 2012 18:21:04 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF2721F87FE for ; Mon, 16 Jul 2012 18:21:04 -0700 (PDT) Received: by yhq56 with SMTP id 56so6375236yhq.31 for ; Mon, 16 Jul 2012 18:21:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-system-of-record; bh=lcJVXa0UWVVtfosL9bLf1W+aMxVW842KfaSAySR0lqg=; b=Pzb6e7TyR5Ll29Sp931uwmXscs3sCX9RwHElatimlx9ARutG6EoYcz4p9pcPEVkRrU 8Fud2+9eOeLAyCJw8BauLD+znQ3jrc6bEzOdFZQ5UG1QKhg8d7gSt9VeCd82/NyGrEyh FauKtFwtQ5q1pQuEe5qva+JylbiPztl4dcxFmkoGQpN2Jy5Aj4dcG4WzMvGky939v/H1 xz3neoukym9BjB39xVlt+wcpVjnEBCLAwyge0YALeYpcXOhl7by2lLC91ZApRNN7CZBe SlTlIr7MMNXckfRDTBBp1TGqsjHCkT5rN/utYAu5neNynyqSO6j4+IgZu1Oe4HsE2hzU Dn7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-system-of-record:x-gm-message-state; bh=lcJVXa0UWVVtfosL9bLf1W+aMxVW842KfaSAySR0lqg=; b=WUzHXoViymvkKDTp9Sib5Ng2T/MT9KJCNhXQRmO9eIVJphmvnE7ReMba5OLW/Fkl+E P8cmODSiSF86xOe1g/2AInDuVFkeyJZVGTYNXIq+76lFUEmGbn37ZNGiSOvn48PivNkd NecWQJAtf8G4dbw3GC0XEtEqSHwtoYP68W+OHme50PwcCSln+xbSuRE2M9yKu9FD7eC4 3T0WX5PKJvX1Y6UOrBxvBcOSO747HWAoUGRMTy1rUcr0BrOwfTEd498skRO5x80NR7mm CJr/vhWn80ro8zLm8nNJ7b2nvdasTWY32tAJo/nGnliVSOt1A1I1p98PXlTMFEwHa3+C +/gg== Received: by 10.60.28.101 with SMTP id a5mr570905oeh.69.1342488109992; Mon, 16 Jul 2012 18:21:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.28.101 with SMTP id a5mr570894oeh.69.1342488109717; Mon, 16 Jul 2012 18:21:49 -0700 (PDT) Received: by 10.182.52.7 with HTTP; Mon, 16 Jul 2012 18:21:49 -0700 (PDT) Date: Mon, 16 Jul 2012 18:21:49 -0700 Message-ID: From: Nandita Dukkipati To: conex@ietf.org Content-Type: multipart/alternative; boundary=e89a8fb2072ee5192404c4fc5ea1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkI9QiNMypz0pRuM5F+ZophHc8p9PBma9PpbrF3nujUXuTUxSm6061mHZ/Iv1iGvD/OaTxRmuFN5CdGVh8c2D6OInyYdPDqDvGJGnV6TAVG66I4xK3GJzBtATvtFOF9BSrUyHBIzIQDhcoy/ZCjbS5G9LAYjJKToXV32iPKrC6Zb3y8INM= Subject: [conex] Call for Conex agenda items at IETF-Vancouver X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 01:21:05 -0000 --e89a8fb2072ee5192404c4fc5ea1 Content-Type: text/plain; charset=ISO-8859-1 Hi, If you would like to give an update of your Conex drafts or give a presentation related to Conex at the upcoming Vancouver meeting, please send us the following information: * Title and draft name * Speaker * Time requested Thank you! Nandita --e89a8fb2072ee5192404c4fc5ea1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

If you would like to give an update of your Conex draf= ts or give a presentation related to Conex at the upcoming Vancouver meetin= g, please send us the following information:

* Title and draft name* Speaker
* Time requeste= d

Thank you!
Nand= ita
--e89a8fb2072ee5192404c4fc5ea1-- From sebastien.jobert@orange.com Wed Jul 18 03:07:32 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B11321F865D for ; Wed, 18 Jul 2012 03:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.402 X-Spam-Level: ** X-Spam-Status: No, score=2.402 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_SUMOF=5, UNPARSEABLE_RELAY=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 nxCXJVod3d3c for ; Wed, 18 Jul 2012 03:07:30 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id AF70B21F8681 for ; Wed, 18 Jul 2012 03:07:29 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 38852324522; Wed, 18 Jul 2012 12:08:19 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 0B48523804B; Wed, 18 Jul 2012 12:08:19 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Wed, 18 Jul 2012 12:08:17 +0200 From: To: Michael Welzl , Jim Gettys , Ingemar Johansson S , Mirja Kuehlewind , "conex@ietf.org" , "iccrg@cs.ucl.ac.uk" Thread-Topic: [Iccrg] Re: [conex] ECN marking over wireless networks Thread-Index: AQHNRI32dcr+jih9uEGeNazVe4C5VZbz+j6AgDmiP4A= Date: Wed, 18 Jul 2012 10:08:17 +0000 Message-ID: <25858_1342606099_50068B13_25858_9256_1_7F67B91079F7C74F9DAB55FC7872661E027F00@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <4FD070F5.8030806@ifi.uio.no> <201206102346.07740.mirja.kuehlewind@ikr.uni-stuttgart.de> In-Reply-To: <201206102346.07740.mirja.kuehlewind@ikr.uni-stuttgart.de> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.7.18.51519 Subject: Re: [conex] [Iccrg] Re: ECN marking over wireless networks X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 10:07:32 -0000 Hi, Thank you very much for your feedbacks on this item, and sorry for the very= long delay to reply. I won't be in Vancouver unfortunately to discuss this with you, but will co= nsider attending the next meetings. Please find below some additional thoughts about this thread. 1) Fairness You suggest Michael to take into account the application requirements in ad= dition to a more basic sharing of the resources. Taking a local decision ha= s also been suggested (I assume that "local" means here: "by the Access Poi= nt", which is normally what is done for ECN marking - the decision is alway= s local). It should be noted that taking into account the application requi= rements would then imply that the Access Point has the knowledge about whic= h types of applications are running over all the terminals... which might b= e quite difficult in practice, and possibly not desirable in some cases. The question that is raised here, I believe, is to understand how ECN marki= ng over the radio segment can help (if it helps...) when combined with exis= ting/already implemented radio resources sharing algorithm (e.g. PF). And h= ow this signal might interact with other mechanisms (TCP, incentives, ...) = to improve the situation in case of radio congestion compared to the case w= here ECN marking is not used. At the end, I agree that it might not be the = most optimal solution (but I'll tend to think that wireless systems always = require some kind of compromise - you might optimize one particular paramet= er at the expense of another). I also agree with Jim that fairness should refer to "transmission opportuni= ties" in this type of wireless systems rather than bandwidth. Thanks also J= im for the details on the Linux drivers, this is quite useful (it seems the= n that in these implementations, a mix between the two models that I briefl= y depicted is considered). What you mentioned about bugs on different drive= rs makes me think that some sort of documentation about expected behavior f= or ECN marking would be useful. Thanks also for the information about CoDel= AQM (that I did not know before) to be considered instead of RED. We'll in= vestigate this. 2) Heterogeneity Of course, radio systems and drivers may have different behaviors. However,= there are some common aspects to all these systems, e.g. the radio transmi= ssion channel has some common properties. I assume that a generic model (or= a few generic models) might be developed (Proportional Fair is for instanc= e a quite common algorithm). Note that this heterogeneity problem is quite common in practice, and appli= es also to other technologies (the various behaviors of forwarding engines = of IP routers is a very good example), but it fortunately did not preclude = developing in the past generic models for the purpose of progressing a comm= on understanding of certain mechanisms. I still really can see benefits in trying to document such ECN marking algo= rithms over wireless networks, even if in practice, a real implementation m= ight differ from those general descriptions. One reason justifying this: EC= N marking over wireless network is mentioned in different documents (e.g. 3= GPP TS 36.300, 26.114, draft "Mobile Communication Congestion Exposure Scen= ario" in Conex WG, ...), how would you use it in practice if you have no id= ea about what is done by the equipment? That being said, I fully agree that no general recommendation can be done a= t this stage, but I would also really encourage people to work on this so t= hat some sort of general recommendations could be developed in the future. = I also agree that Conex approach might help on the fairness item, with some= adaptations. Cheers, S=E9bastien -----Message d'origine----- De=A0: iccrg-bounces@cs.ucl.ac.uk [mailto:iccrg-bounces@cs.ucl.ac.uk] De la= part de Mirja Kuehlewind Envoy=E9=A0: dimanche 10 juin 2012 23:46 =C0=A0: conex@ietf.org Cc=A0: iccrg@cs.ucl.ac.uk Objet=A0: [Iccrg] Re: [conex] ECN marking over wireless networks Hi Micheal, =20 just two quick comment on your two points: > > 1) Fairness. If I get to send at a lower rate, I waste more of > everyone's resources. My own benefit is also reduced. Should I send even > less than what the system now allows me, to be friendly to everyone, or > should I send as much as I can? I might be in worse conditions than > others; does that mean that I should be even worse off? I think the > correct answer would have to be a function of the impact that my own > traffic has on the utility that everyone else is getting out of the > network resources, and the utility that I am getting out of them. We can > assume a general case of a strictly concave function and solve the > problem with calculations a la proportional fairness... but then again, > not all applications have such utility functions (e.g. VoIP is > different, and using e.g. VoIP over WiFi is not at all uncommon). A good > solution would therefore have to make a local decision that is based on > knowing which applications are used. Yes, you should make the decision locally! But you need some information ab= out=20 the network state. ECN is only the signal protocol that provides you this= =20 information. ECN says you should react on this signal the same way as you= =20 would react to loss but that doesn't you have to halve your rate. ECN does= =20 not specify any action that will actually change your traffic; it's a signa= l=20 protocol only. > > 2) Heterogeneity: wireless systems differ greatly. For instance, in [1] > we found that, **in total absence of real noise**, TCP's throughput > across a WLAN can very much depend on the chosen rate adaptation > mechanisms. Essentially, this means that some rate adaptation mechanisms > do a bad job at trying to detect noise, and mistake collisions for it. > They then switch to a lower rate when they really shouldn't (on a side > note, Minstrel, available in MadWifi, seemed to always work best). Now, > note that in a practical WLAN you don't even know which rate adaptation > mechanism is chosen by the individual hosts participating! Under such > conditions, how would you make an ECN-marking rule work well for > everyone? Yes we could design a rule, but that would have to depend on > the driver and even the configuration of not only the AP but all the > hosts currently involved. I believe that's the point we are talking about. In general ECN/RED should= =20 work no matter what network you are looking at. The only question is, if we= =20 know something specific about the link, as we do know for a mobile networks= ,=20 can we do something better (like adjusting the RED parameters). And for=20 mobile network, I believe, this will be specific for each operator as they= =20 know their network best. Mirja > > To conclude: yes I think this is interesting stuff, and worth > investigating as a research topic. As such it's perfectly fine to > discuss it at ICCRG (I suggest: on the basis of measurements). And maybe > (an adaptation of) conex can solve problem #1 above - but not problem > #2. It is therefore clear to me that we cannot make a general > recommendation at this stage, and I think it's very likely that, even > after carrying out a lot of research on this, no *general* > recommendation can ever be made. > > Cheers, > Michael > > [1] Naeem Khademi, Michael Welzl, Stein Gjessing: "Experimental > Evaluation of TCP Performance in Multi-rate 802.11 WLANs", accepted for > publication, IEEE WoWMoM 2012, 25-28 June 2012, San Francisco, > California, USA. > > On 5/9/12 10:48 PM, sebastien.jobert@orange.com wrote: > > Hi, > > > > There has been some discussion during the IETF 83 in Paris in ICCRG > > and CONEX WG about relevant ECN marking algorithms over wireless > > networks. > > > > Some aspects related to this topic are discussed in this draft: > > http://www.ietf.org/id/draft-jobert-tsvwg-pre-congest-notif-mobile-00.p= df > >, briefly introduced during ICCRG meeting. > > > > This email aims at starting some discussion on the mailing lists of > > ICCRG and CONEX, as requested by the chairs after the discussions > > during IETF 83. > > > > Essentially, the main aspect pointed out during the discussions was > > that there might benefits in taking into account the radio conditions > > of the mobile terminal for ECN marking over the radio segment and for > > congestion-volume counting. The reason for this is that it requires > > more radio resources to transmit the same amount of data to a terminal > > in bad radio conditions compared to a terminal in good radio conditions. > > > > As an introduction to the discussion, it might be useful to mention > > that different potential /use cases/ for ECN marking involving the > > mobile terminal could be envisaged: > > > > 1.interaction with TCP > > > > 2.adapt the coding rate of adaptive application (e.g. adaptive > > streaming, etc.), as suggested in 3GPP TS 36.300 document > > > > 3.stop/delay the non-urgent applications (background tasks in the > > terminal, etc.) > > > > 4.congestion-volume counting (as for Conex related use cases) > > > > This list is obviously non-exhaustive, and shows that depending on the > > final utilization of the congestion notification, different algorithms > > for ECN marking over the radio segment might be imagined. The most > > optimal algorithm certainly depends on the final objective. > > > > From the comments received during the discussion, it seems that the > > first ECN marking algorithm over the radio segment that comes to most > > people's mind is to consider an average queue length exceeding a given > > threshold, as for RED. It should be noted that because the radio > > segment shares the radio resource among several terminals, one > > dedicated queue per terminal is in general considered. > > > > Therefore, if one would like to apply RED over a wireless segment, it > > should be clarified whether it would be applied independently on each > > dedicated queue per terminal (n instances of RED considered for the > > radio segment), or on the sum of all the dedicated queues (1 single > > instance of RED considered for the radio segment). This would lead to > > two different ECN marking /criteria/: > > > > 1.RED based on the individual queue of each terminal > > > > 2.RED based on a single shared queue between all the terminals > > > > Several remarks were raised during the presentation of the draft in > > ICCRG and the discussion in CONEX: > > > > -On the interactions with TCP (use case #1 listed above), it was > > mentioned that TCP works on a longer timescale relative to the > > wireless channel. In other words: the radio conditions may vary more > > quickly than TCP reactions. This is correct, however, it should be > > mentioned that the objective of ECN marking over the radio segment is > > not to replace the existing radio schedulers, which already provide a > > suitable control loop over these shorter time scales. As an example, > > the very common Proportional Fair (PF) algorithm aims at addressing > > exactly this point, by trying to optimize the allocation of radio > > resources (the terminals in good instantaneous radio conditions are > > favored compared to the others, as to optimize the cell capacity, > > while certain fairness is ensured in the longer term by taking into > > account also the averaged throughputs delivered to the terminals). > > > > -Still regarding the interactions with TCP (use case #1 listed above), > > assume now that a PF algorithm is used to control the allocation of > > radio resources. It was mentioned also that if it is assumed that ECN > > marking is done according to the individual queue of each terminal > > (criteria #1 listed above), then a terminal in bad radio conditions > > will already experience ECN marking more often without the need to > > weight the probability of the ECN marking with the radio conditions of > > the terminal. This is due to the fact that PF provides higher > > throughput to terminals in good averaged radio conditions than in bad > > averaged radio conditions. Actually, the amount of ECN marking will > > depend in this case whether the throughput required to transmit the > > data to a particular terminal is lower than the throughput provided to > > this terminal by PF; if not, then no ECN marking should happen for > > this terminal in these conditions (even during congested periods > > actually). > > > > -Based on this discussion, it seems to me that the interaction of ECN > > marking with TCP should not be analyzed in terms of benefits it brings > > to control the allocation of resources over the radio segment, which > > is already under the control of the radio scheduler. It seems that > > this second control loop provided by ECN marking interacting with TCP > > would rather aim at indicating when the traffic rate of a terminal > > exceeds the throughput provided by PF to this terminal, which could be > > useful for use case #2 (coding rate adaptation). Basically, it is > > expected that this second control loop would try to "align" with the > > throughput provided by the first one (keeping in mind that PF provides > > throughputs varying with time). > > > > -The same example but now with the ECN marking criteria #2 instead of > > #1 raises however issues. Indeed, in case the throughput required to > > transmit the data to one particular terminal is lower than the > > throughput provided to this terminal, this will lead to ECN marking > > for all the terminals, even the ones below the PF throughput, which is > > a situation that should be avoided when interaction with TCP is > > desirable. Excessive traffic consumption on one terminal should not > > impact the others (i.e. should not lead to the generation of ECN > > marking for the others). Definitely, the criteria #1 does not seem a > > good idea when interaction with TCP is desired. > > > > -Considering the use case #3 depicted earlier now, it should be noted > > however that the previous situation with PF + ECN marking based on > > individual queues (criteria #1) has some limitation. Indeed, in case > > of radio congestion (assume here that radio congestion means that all > > the radio resources are used and are not enough to transmit all the > > data to be transmitted to all the terminals - a more accurate > > definition might be found), some of the terminals may not received ECN > > marking, as indicated before (in case they require less than what PF > > can provide to them). Perhaps some of the data transmitted to these > > non-notified terminals are not so critical and might be delayed, as to > > free resources to the other users with more important traffic to be > > exchanged. The depicted situation does not provide incentives to do > > this, because ECN marking only applies to some users. It is the reason > > why it might be interesting to consider other ECN marking algorithms > > (which might not aim at interacting necessarily with TCP; BTW not all > > the applications are running over TCP), as to inform about the > > congestion situation. The idea is to say to the end user: "Hey! The > > system starts being full, the PF algorithm will still provide you with > > some network resources, but if some of your data can be delayed, > > please do so!" Of course, this kind of approach might be coupled with > > congestion-volume counting / CONEX use cases, to provide incentives. > > > > -Let's take a practical example to illustrate (note sure it is the > > best one, but it is the one that comes to my mind.): you need to go to > > some administration to collect some administrative document - say, a > > voting card to elect your new president. There is already a long > > queue, but you could pass with a "certain priority" because what you > > need to do is faster than what other people have to do. However, if > > you collect your document, you consume resources of the system that > > will not be available to the others during this time - the person in > > front of you will be busy giving you your document. And what you need > > to do is not urgent - the election is not tomorrow, you will have time > > to come back later. Perhaps you would like to be fair with the other > > people having more urgent things to do and waiting in the queue, and > > you will not wait and instead come back later? And perhaps a signal > > indicating the congestion might be useful (it is probably good to know > > if the queue is long or not, rather than waiting without information). > > > > -Considering the use case #4 depicted earlier now on congestion-volume > > counting: it seems logical to me that the count would take into > > account the real network resource usage rather than simply the number > > of bits transmitted. This would provide again incentives to users in > > bad radio conditions to delay non-urgent network usage. Moreover, an > > interesting question which should be raised would be to define what > > corresponds to a "congested period" for the radio segment: is it only > > when the terminal exceeds its PF rate, or should a congestion period > > be considered when the system starts being full/is full? This might > > trigger different ECN marking algorithms on the wireless segment. > > > > I had noted two other comments from the discussions in IETF 83: > > > > -TCP middlebox accelerating TCP window growth: some comment was made > > on the mic, however I am not sure that I understood what this device > > is supposed to do; would anyone of you have some reference on this? > > > > -Retransmission over the radio segment: should it be taken into > > account as well for congestion-volume counting? It would mean that a > > lost packet that is retransmitted by the low layers should be counted > > twice? (after all, if it was retransmitted by TCP, it would have been > > counted twice as well, right?) > > > > Feedback on this discussion is welcomed. Thanks in advance. > > > > Cheers, > > > > *S=E9bastien JOBERT* > > Orange Expert "Future Networks", network synchronization and QoS in > > mobile networks > > *Orange Labs, Networks & Carriers - France Telecom R&D* > > sebastien.jobert@orange.com > > > > > > > > _______________________________________________ > > conex mailing list > > conex@ietf.org > > https://www.ietf.org/mailman/listinfo/conex > > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex --=20 ------------------------------------------------------------------- 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 ------------------------------------------------------------------- _______________________________________________ Iccrg mailing list Iccrg@cs.ucl.ac.uk http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From nanditad@google.com Tue Jul 24 22:40:18 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5D8A21F851B for ; Tue, 24 Jul 2012 22:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 HauV3gl5P2+7 for ; Tue, 24 Jul 2012 22:40:18 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 13DE121F8517 for ; Tue, 24 Jul 2012 22:40:17 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so624371obb.31 for ; Tue, 24 Jul 2012 22:40:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-system-of-record; bh=fJkEK+rCopbkF2xQdDU8ReB+Inv7olJEhU+veiUIduw=; b=jy1cwfIdQQtZH0T1YPRNZaULaHFD8MEB2UBP7X7xX9DwBVovciOp8UFegfBeFEpfad 8w5AXvjx+hQai6ZkAqeK1ih3t/x/YmM0Cs9vnTuw826nVPgIrr5lou2hnjuw8YizsHDv LVEVtMMBAHDYJn6rkuUMfUspWWLiJoNOkavoezHzrrKJtHFgM1JneptgEhsZ37S85COV Gdcws9QlLuuBzHtngGUDZNG6T2GTRsMd9eeQL1qdKjTZtbu3C3Zqn0/TS5g3mgYwr0wg 9ZbpIAjYnGSHE/HsUGFkZEAI6mmyhw9znLIypM2yf4pJlMFlgQ6bZdrI+s7D4j5r/eoi pqlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-system-of-record:x-gm-message-state; bh=fJkEK+rCopbkF2xQdDU8ReB+Inv7olJEhU+veiUIduw=; b=TAKrkQpZHRpBI3mb1oW64AiuH7lEzxIcgJb3iV2C6yQdAh2HRZF2Mqt0aYqANYP0zA W12Y7SI9proBGJixGEgOz2KAOGv1AnVxmpEV8MkE0gm2Nw3luh/oYT1NPFLrMMt3XlGN HL1nBhfGdYbcwiPh7HJ5s2lWKko9iHTNjE3hkleOhwo7jpoRA6Oy2CvE06YbRv0z7w2M 1qfWTYkoWvHXGnw/4u7PH0GkDnTt6LKTaPegIjzop91eyQFiLmml7uPBOz5yM6dNXBZP j221ARVCIcOSqVSf5wNqJ2B8ejHJzz4IyQyF7txHntiXWO1sg9FyXN7+N9bwmUt2M5fx r7AQ== Received: by 10.182.111.74 with SMTP id ig10mr32022991obb.14.1343194817489; Tue, 24 Jul 2012 22:40:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.111.74 with SMTP id ig10mr32022983obb.14.1343194817377; Tue, 24 Jul 2012 22:40:17 -0700 (PDT) Received: by 10.182.52.7 with HTTP; Tue, 24 Jul 2012 22:40:16 -0700 (PDT) Date: Tue, 24 Jul 2012 22:40:16 -0700 Message-ID: From: Nandita Dukkipati To: conex@ietf.org Content-Type: multipart/alternative; boundary=14dae9399ceff4355f04c5a0e912 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlNe3Na/aV+oFSW48LtfsQdzX6hUtwwfFj1GDJjfFiQLSu5Sqlwj1QDcVkwpGJ7fyMBKJ31ttqPC6/4vC7SKIsZEP+tgagmkTFzhcNbYrpyiaHQ6PuEG+rBkS1FjPzjTi+tAyUPl8Gnv4oUe3ygfBd4GfM8jyceWGCD+hH/iobI7ka/IPg= Subject: [conex] Conex agenda for Vancouver meeting X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 05:40:18 -0000 --14dae9399ceff4355f04c5a0e912 Content-Type: text/plain; charset=ISO-8859-1 Please find the agenda here- http://www.ietf.org/proceedings/84/agenda/agenda-84-conex There is room in the agenda; if you would like to present anything conex related, please let me know. Nandita --14dae9399ceff4355f04c5a0e912 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Please find the agenda here-

There is room in the agenda; if you= would like to present anything conex related, please let me know.

Nandita
--14dae9399ceff4355f04c5a0e912-- From menth@informatik.uni-tuebingen.de Tue Jul 24 23:55:22 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92EB021F8540 for ; Tue, 24 Jul 2012 23:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 PhhuwCWtGN0j for ; Tue, 24 Jul 2012 23:55:22 -0700 (PDT) Received: from mx5.informatik.uni-tuebingen.de (mx5.Informatik.Uni-Tuebingen.De [134.2.12.32]) by ietfa.amsl.com (Postfix) with SMTP id 755B221F848A for ; Tue, 24 Jul 2012 23:55:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 0A02352A4 for ; Wed, 25 Jul 2012 08:55:18 +0200 (MEST) X-Virus-Scanned: amavisd-new at informatik.uni-tuebingen.de Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx5.informatik.uni-tuebingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvpmNm8S2xIN for ; Wed, 25 Jul 2012 08:55:13 +0200 (MEST) Received: from zcs-bs.informatik.uni-tuebingen.de (zcs-bs.Informatik.Uni-Tuebingen.De [134.2.12.62]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 7CA4B527B for ; Wed, 25 Jul 2012 08:55:13 +0200 (MEST) Received: from [134.2.11.131] (chaos.Informatik.Uni-Tuebingen.De [134.2.11.131]) by zcs-bs.informatik.uni-tuebingen.de (Postfix) with ESMTP id 11DED4B6746C for ; Wed, 25 Jul 2012 08:55:13 +0200 (CEST) Message-ID: <500F9852.5020401@informatik.uni-tuebingen.de> Date: Wed, 25 Jul 2012 08:55:14 +0200 From: Michael Menth User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: conex@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------040105090400030709090008" Subject: Re: [conex] Conex agenda for Vancouver meeting X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 06:55:22 -0000 This is a multi-part message in MIME format. --------------040105090400030709090008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Nandita, we have new, consolidated performance results for ConEx-based congestion policing using TCP adapted for ConEx with exact ECN feedback. Unfortunatley, we will not make it to Vancouver. This is just to let you know that we continue our activities. Kind regards, Michael Am 25.07.2012 07:40, schrieb Nandita Dukkipati: > Please find the agenda here- > http://www.ietf.org/proceedings/84/agenda/agenda-84-conex > > There is room in the agenda; if you would like to present anything > conex related, please let me know. > > Nandita > > > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex -- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://kn.inf.uni-tuebingen.de --------------040105090400030709090008 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Nandita,

we have new, consolidated performance results for ConEx-based congestion policing using TCP adapted for ConEx with exact ECN feedback. Unfortunatley, we will not make it to Vancouver. This is just to let you know that we continue our activities.

Kind regards,

    Michael

Am 25.07.2012 07:40, schrieb Nandita Dukkipati:
Please find the agenda here-

There is room in the agenda; if you would like to present anything conex related, please let me know.

Nandita


_______________________________________________
conex mailing list
conex@ietf.org
https://www.ietf.org/mailman/listinfo/conex


-- 
Prof. Dr. habil. Michael Menth
University of Tuebingen
Faculty of Science
Department of Computer Science
Chair of Communication Networks
Sand 13, 72076 Tuebingen, Germany
phone: (+49)-7071/29-70505
fax: (+49)-7071/29-5220
mailto:menth@uni-tuebingen.de
http://kn.inf.uni-tuebingen.de


--------------040105090400030709090008-- From Alfons.Martin@informatik.uni-tuebingen.de Thu Jul 26 04:55:24 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0B421F85C9 for ; Thu, 26 Jul 2012 04:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448] 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 WWEEOln5iI-0 for ; Thu, 26 Jul 2012 04:55:23 -0700 (PDT) Received: from mx3.informatik.uni-tuebingen.de (mx3.Informatik.Uni-Tuebingen.De [134.2.12.26]) by ietfa.amsl.com (Postfix) with SMTP id 40A0F21F85A8 for ; Thu, 26 Jul 2012 04:55:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id 2A3A55317 for ; Thu, 26 Jul 2012 13:55:21 +0200 (MEST) X-Virus-Scanned: amavisd-new at informatik.uni-tuebingen.de Received: from mx3.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx3.informatik.uni-tuebingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CwJ7tJKJl9Ux for ; Thu, 26 Jul 2012 13:55:19 +0200 (MEST) Received: from zcs-pu.informatik.uni-tuebingen.de (zcs-pu.Informatik.Uni-Tuebingen.De [134.2.12.61]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id 7FAE652E4 for ; Thu, 26 Jul 2012 13:55:19 +0200 (MEST) Received: from [134.2.11.132] (prometheus.Informatik.Uni-Tuebingen.De [134.2.11.132]) by zcs-pu.informatik.uni-tuebingen.de (Postfix) with ESMTP id DD52A1C15E8F for ; Thu, 26 Jul 2012 13:55:19 +0200 (CEST) Message-ID: <50113043.4090106@informatik.uni-tuebingen.de> Date: Thu, 26 Jul 2012 13:55:47 +0200 From: Alfons Martin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: conex@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: [conex] New simulation results X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 11:55:24 -0000 Hi all, we have new simulations results for ConEx-based congestion policing. They are based on accurate ECN feedback.http://atlas2.informatik.uni-tuebingen.de/papers/Paper12-Sub-2.pdf Comments are welcome. Alfons Martin -- Alfons Martin, M.Sc. University of Tuebingen Wilhelm-Schickard-Institute of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70508, fax: (+49)-7071/29-5220 mailto: Alfons.Martin@informatik.uni-tuebingen.de From nanditad@google.com Sun Jul 29 18:12:40 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36A5D21F8686 for ; Sun, 29 Jul 2012 18:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 iH6ucBxsjSgn for ; Sun, 29 Jul 2012 18:12:39 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id A978C21F867F for ; Sun, 29 Jul 2012 18:12:39 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so9328583obb.31 for ; Sun, 29 Jul 2012 18:12:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :x-system-of-record; bh=Mq+LsKQ6PxxzMVhPa6ZZb4zmTZ6G8W4nlGOvFTYNt/8=; b=REKJVx5qwRhyI/lU9DoOTUNhRru3FM38SUaFMzTW1062o0Fga2fyCyttJ+WmvQ/7Pi kvsejOvL8gQN5VRLMWWLFeTd0XCqpoto/xnU647UMXOy8E5TcbZeoEjkgL85gzAF7jrY II6gIuY8FXZ2wNGSIC4MdVotnjnIliPLu+rcHN6P8NwC+4dnb3/PoeO9Bea5fRW2YvDj swIOe4rT74z8dEAWaPuACWBhmbPFDBNzxYbqJCKO4JtiOwWszpFkQ4MdvWoGY6KguMyt yqh7gjokaEOjakY64R0jmRjskoYIXU1NdGEYv7j4EGyQV8cOftxuPKDqkdVeSAQPk7Hz me8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :x-system-of-record:x-gm-message-state; bh=Mq+LsKQ6PxxzMVhPa6ZZb4zmTZ6G8W4nlGOvFTYNt/8=; b=VA6feLqIXirAVyeVHvJUOh0kYaiwP5LUdB8C30Vxvy59AAeG2bYZQjW73vLjlDe1uS 8tpRyjmZUkjJN0hhhj2kEr24pjoLvlCU6uxpkvipmhYKDn6gyuOpQsdOczKdR3IydLmA I4HQZPD5hdasy1AMKEf6A4ykOY+C7IuVuWSIV8Mz2Petv5xUTj7JZ7gAX4kTnuDcu26d HP3Z62UIOpMro7lVtZ2qAXayQoCt8oTOVqv0VedFpG/cA414oWKNqW8+lCtr2tgiWRL/ XNEHDhv/F09IWWFIxOyMyPNwf3LAk3Dgbao4FpmvFJGZVDcXpcHXDunfUIXMWNL8w5de nYyw== Received: by 10.182.53.103 with SMTP id a7mr14892521obp.3.1343610759289; Sun, 29 Jul 2012 18:12:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.53.103 with SMTP id a7mr14892506obp.3.1343610759083; Sun, 29 Jul 2012 18:12:39 -0700 (PDT) Received: by 10.182.52.7 with HTTP; Sun, 29 Jul 2012 18:12:38 -0700 (PDT) Date: Sun, 29 Jul 2012 18:12:38 -0700 Message-ID: From: Nandita Dukkipati To: conex@ietf.org Content-Type: multipart/alternative; boundary=f46d0447963102f7e404c601c29d X-System-Of-Record: true X-Gm-Message-State: ALoCoQm+nr2TRpqByqoQx7rIyrvPHbo244bqnLsjjKD5mdVKmr+3nKIDYTlkf4whIzyHVnQ+941tULAmy5daPrM6J5GESzqIrJQyb2lFgZjuE60qwJ2OYOXXm0HKkQTskQOVQ1Ru5iwdK/La53kOVUIqcIqry4yHkcaA9jQfmfqFIbqnKbRHmjw= Subject: [conex] Conex IETF-84 slides X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 01:12:40 -0000 --f46d0447963102f7e404c601c29d Content-Type: text/plain; charset=ISO-8859-1 Speakers: Please send the slides to the chairs by Tue noon at the latest. The session is scheduled for Wed. 08/01 1-3pm. Nandita --f46d0447963102f7e404c601c29d Content-Type: text/html; charset=ISO-8859-1 Speakers: Please send the slides to the chairs by Tue noon at the latest.

The session is scheduled for Wed. 08/01 1-3pm.

Nandita


--f46d0447963102f7e404c601c29d--