Re: [re-ECN] ECN fundamentals pt2/2 (was: Re: Name for BoF?)

<philip.eardley@bt.com> Fri, 02 October 2009 17:04 UTC

Return-Path: <philip.eardley@bt.com>
X-Original-To: re-ecn@core3.amsl.com
Delivered-To: re-ecn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 648FB3A6890 for <re-ecn@core3.amsl.com>; Fri, 2 Oct 2009 10:04:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.919
X-Spam-Level:
X-Spam-Status: No, score=-2.919 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HAh75sIqaXZs for <re-ecn@core3.amsl.com>; Fri, 2 Oct 2009 10:04:27 -0700 (PDT)
Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id EF1523A67B0 for <re-ecn@ietf.org>; Fri, 2 Oct 2009 10:04:26 -0700 (PDT)
Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 18:05:53 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 2 Oct 2009 18:05:53 +0100
Message-ID: <4A916DBC72536E419A0BD955EDECEDEC063638BF@E03MVB1-UKBR.domain1.systemhost.net>
In-Reply-To: <001201ca4371$660ec590$322c50b0$@com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [re-ECN] ECN fundamentals pt2/2 (was: Re: Name for BoF?)
Thread-Index: AcpDOlEVoUU3UAUhT+KpRMIF8zfg+AAAtVQwAAzNAeAABCjlUA==
From: <philip.eardley@bt.com>
To: <jbabiarz@istop.com>, <mirja.kuehlewind@ikr.uni-stuttgart.de>, <re-ecn@ietf.org>, <menth@informatik.uni-wuerzburg.de>
X-OriginalArrivalTime: 02 Oct 2009 17:05:53.0982 (UTC) FILETIME=[99DF05E0:01CA4382]
Subject: Re: [re-ECN] ECN fundamentals pt2/2 (was: Re: Name for BoF?)
X-BeenThere: re-ecn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: re-inserted explicit congestion notification <re-ecn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/re-ecn>, <mailto:re-ecn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/re-ecn>
List-Post: <mailto:re-ecn@ietf.org>
List-Help: <mailto:re-ecn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/re-ecn>, <mailto:re-ecn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Oct 2009 17:04:28 -0000

Agree with you joe. 

One of the barriers to investment is that increasing capacity may not lead to better e2e qos (because the problem is somewhere else). By exposing information about congestion, it should be easier to assign blame correctly about where the bottleneck is - and therefore improve the incentive to invest in more capacity (I can tell you're a good guy, so shift my traffic to you - you gain by getting the connection etc charge). 

Maybe that sounds a rather indirect argument - but given there are incentives to invest in capacity today, I think better information about the bottlenecks should help the incentives to invest. 

The obvious counter-example is where a consumer has only one choice of local provider and then indeed it does seem that the ISP can make "more money because their network is congested". But the problem here is that the ISP has a termination monopoly, which basically needs to be tackled by regulation in some shape or form - there is exactly the same issue today. 

-----Original Message-----
From: Joe Babiarz [mailto:jbabiarz@istop.com] 
Sent: 02 October 2009 16:03
To: Eardley,PL,Philip,DEE1 R; mirja.kuehlewind@ikr.uni-stuttgart.de; re-ecn@ietf.org; menth@informatik.uni-wuerzburg.de
Subject: RE: [re-ECN] ECN fundamentals pt2/2 (was: Re: Name for BoF?)

Would like to add that the protocol should be designed so that it does not
discourage ISPs from increasing capacity of their networks. We do not want
ISPs be making more money because their network is congested.

Regards, Joe.
jbabiarz@istop.com

-----Original Message-----
From: re-ecn-bounces@ietf.org [mailto:re-ecn-bounces@ietf.org] On Behalf Of
philip.eardley@bt.com
Sent: Friday, October 02, 2009 5:08 AM
To: mirja.kuehlewind@ikr.uni-stuttgart.de; re-ecn@ietf.org;
menth@informatik.uni-wuerzburg.de
Subject: Re: [re-ECN] ECN fundamentals pt2/2 (was: Re: Name for BoF?)

I agree.

In practice I guess that the consumer will have a choice between (say) 3
tiers of service (basic, plus, super advanced). although different monthly
congestion allowances (& maybe difference maximum congestion rates) will be
part of that, most consumers won't really understand it (just as today most
don't understand what 20mb/s or 1gb mean). But there are independent experts
that check comparative performance of different ISPs, and you can run a
program to check what performance you actually get.



-----Original Message-----
From: re-ecn-bounces@ietf.org [mailto:re-ecn-bounces@ietf.org] On Behalf Of
Mirja Kuehlewind
Sent: 02 October 2009 09:28
To: re-ecn@ietf.org; menth@informatik.uni-wuerzburg.de
Subject: Re: [re-ECN] ECN fundamentals pt2/2 (was: Re: Name for BoF?)

Hi Michael,

On Friday 02 October 2009 07:32:18 Michael Menth wrote:
> Apart from that, I wonder whether a monthly congestion allowance or a
> maximum congestion rate can be sold to the customer because that is more
> abstract and harder to verify for the user. Even I do not know what I
> get for a congestion allowance of 1 MB/month or a maximum congestion
> rate of 10 KB/s. That was one of the criticisms I've heard when
> discussing about re-feedback. Opinions?
>
I don't see that you have to sell the congestion rate to the costumer. It's 
just one part of the contract which will have some more or less meaningful 
names like "fast access" or "high speed access". People don't know what the 
max. access speed in todays contracts means neither...

Mirja



-- 
-------------------------------------------------------------------
Dipl.-Ing. Mirja Kühlewind
Institute of Communication Networks and Computer Engineering (IKR)
University of Stuttgart, Germany
Pfaffenwaldring 47, D-70569 Stuttgart

web: www.ikr.uni-stuttgart.de
email: mirja.kuehlewind@ikr.uni-stuttgart.de
tel: +49(0)711/685-67973
-------------------------------------------------------------------
_______________________________________________
re-ECN mailing list
re-ECN@ietf.org
https://www.ietf.org/mailman/listinfo/re-ecn
_______________________________________________
re-ECN mailing list
re-ECN@ietf.org
https://www.ietf.org/mailman/listinfo/re-ecn
No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.409 / Virus Database: 270.14.3/2409 - Release Date: 10/02/09
06:46:00