Re: [conex] ConEx as sender side only modification
Ingemar Johansson S <ingemar.s.johansson@ericsson.com> Tue, 15 November 2011 08:26 UTC
Return-Path: <ingemar.s.johansson@ericsson.com>
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 C8E9621F8D30 for <conex@ietfa.amsl.com>; Tue, 15 Nov 2011 00:26:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a+rql-trzlir for <conex@ietfa.amsl.com>; Tue, 15 Nov 2011 00:26:01 -0800 (PST)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 99DFF21F8D1F for <conex@ietf.org>; Tue, 15 Nov 2011 00:26:01 -0800 (PST)
X-AuditID: c1b4fb3d-b7c26ae0000035b9-a0-4ec2221862df
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 68.29.13753.81222CE4; Tue, 15 Nov 2011 09:26:00 +0100 (CET)
Received: from ESESSCMS0366.eemea.ericsson.se ([169.254.1.53]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Tue, 15 Nov 2011 09:25:59 +0100
From: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
To: Mirja Kuehlewind <mirja.kuehlewind@ikr.uni-stuttgart.de>, "conex@ietf.org" <conex@ietf.org>
Date: Tue, 15 Nov 2011 09:25:57 +0100
Thread-Topic: [conex] ConEx as sender side only modification
Thread-Index: Acyi7G1lvsYaNDVfT3ugbT7K+KHp6wAgr58g
Message-ID: <DBB1DC060375D147AC43F310AD987DCC42D7A89A6F@ESESSCMS0366.eemea.ericsson.se>
References: <20111030141755.21962.83789.idtracker@ietfa.amsl.com> <20111107160135.GA45061@verdi> <DBB1DC060375D147AC43F310AD987DCC42D7A26772@ESESSCMS0366.eemea.ericsson.se> <201111141742.38336.mirja.kuehlewind@ikr.uni-stuttgart.de>
In-Reply-To: <201111141742.38336.mirja.kuehlewind@ikr.uni-stuttgart.de>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: sv-SE, en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [conex] ConEx as sender side only modification
X-BeenThere: conex@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Congestion Exposure working group discussion list <conex.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/conex>, <mailto:conex-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/conex>
List-Post: <mailto:conex@ietf.org>
List-Help: <mailto:conex-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/conex>, <mailto:conex-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Nov 2011 08:26:02 -0000
Thanks This then means that a policer need to give some extra slack for normal TCP. It is perhaps doable with a policer that somehow has access to the TCP acks in the reverse direction and then can determine both RTT with a reasonable accuracy and also if TCP ECE is modified according to (http://tools.ietf.org/id/draft-kuehlewind-conex-tcp-modifications-01.txt) Or is this perhaps simpler ? /Ingemar PS Realized that I got things a bit backwards in my question below, thought that ECE is clamped to 1 for an RTT... > -----Original Message----- > From: Mirja Kuehlewind [mailto:mirja.kuehlewind@ikr.uni-stuttgart.de] > Sent: den 14 november 2011 17:43 > To: conex@ietf.org > Cc: Ingemar Johansson S > Subject: Re: [conex] ConEx as sender side only modification > > Hi Ingemar, > > yes there are only sender-side modification needed. If you > only have the 'classic' ECN, you will only be able to get (at > max) one congestion notification per RTT. If there is more > than one CE marking per RTT you will underestimate the congestion. > > Mirja > > > On Monday 14 November 2011 11:16:04 Ingemar Johansson S wrote: > > Hi > > > > Have not been able to follow the ConEx list in detail but reading > > http://tools.ietf.org/id/draft-briscoe-conex-initial-deploy-00.txt > > I can see that received side modifications are optional. > > This is of course interesting at least if consinder the > normal server > > client architecture as it is easier to modify a million > servers than a > > zillion clients. Assuming that I read right... > > How does it work with TCP, I know TCP modifications have been > > considered to make TCP echo back the exact correct number > of ECN-CE to > > the server. Does this then mean that a TCP flow (unmodified > TCP) will > > state a higher congestion level in the dest-opts than the actual ? > > > > /Ingemar > > > > ================================= > > INGEMAR JOHANSSON M.Sc. > > Senior Researcher > > > > Ericsson AB > > Wireless Access Networks > > Labratoriegränd 11 > > 971 28, Luleå, Sweden > > Phone +46-1071 43042 > > SMS/MMS +46-73 078 3289 > > ingemar.s.johansson@ericsson.com > > www.ericsson.com > > ================================= > > _______________________________________________ > > conex mailing list > > conex@ietf.org > > https://www.ietf.org/mailman/listinfo/conex > > > > -- > ------------------------------------------------------------------- > Dipl.-Ing. Mirja Kühlewind > 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 > ------------------------------------------------------------------- >
- [conex] I-D Action: draft-ietf-conex-destopt-01.t… internet-drafts
- [conex] draft-ietf-conex-destopt-01.txt John Leslie
- [conex] byte-counting in conex-destopt John Leslie
- Re: [conex] draft-ietf-conex-destopt-01.txt Mirja Kuehlewind
- Re: [conex] byte-counting in conex-destopt Mirja Kühlewind
- Re: [conex] draft-ietf-conex-destopt-01.txt Mirja Kuehlewind
- [conex] ConEx as sender side only modification Ingemar Johansson S
- Re: [conex] ConEx as sender side only modification Mirja Kuehlewind
- Re: [conex] ConEx as sender side only modification Ingemar Johansson S
- Re: [conex] ConEx as sender side only modification Mirja Kuehlewind
- Re: [conex] ConEx as sender side only modification Bob Briscoe
- Re: [conex] ConEx as sender side only modification Scheffenegger, Richard
- Re: [conex] ConEx as sender side only modification Ingemar Johansson S
- Re: [conex] ConEx as sender side only modification Matt Mathis