Re: [re-ECN] Viability issue #1

<toby.moncaster@bt.com> Thu, 05 November 2009 12:42 UTC

Return-Path: <toby.moncaster@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 4084E3A68DA for <re-ecn@core3.amsl.com>; Thu, 5 Nov 2009 04:42:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.234
X-Spam-Level:
X-Spam-Status: No, score=-3.234 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599, 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 fTyqWvgwWwhw for <re-ecn@core3.amsl.com>; Thu, 5 Nov 2009 04:41:59 -0800 (PST)
Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 24FD43A696A for <re-ecn@ietf.org>; Thu, 5 Nov 2009 04:41:58 -0800 (PST)
Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Nov 2009 12:42:20 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 5 Nov 2009 12:41:51 -0000
Message-ID: <AEDCAF87EEC94F49BA92EBDD49854CC70DCB16DC@E03MVZ1-UKDY.domain1.systemhost.net>
In-Reply-To: <4AF26B57.3030601@thinkingcat.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [re-ECN] Viability issue #1
Thread-Index: Acpd3h4DyggAYROQQryg6iI+cM/ImgANo4KA
References: <4AF26B57.3030601@thinkingcat.com>
From: <toby.moncaster@bt.com>
To: <leslie@thinkingcat.com>, <re-ecn@ietf.org>
X-OriginalArrivalTime: 05 Nov 2009 12:42:20.0366 (UTC) FILETIME=[6A4436E0:01CA5E15]
Subject: Re: [re-ECN] Viability issue #1
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: Thu, 05 Nov 2009 12:42:00 -0000

> -----Original Message-----
> From: re-ecn-bounces@ietf.org [mailto:re-ecn-bounces@ietf.org] On
> Behalf Of Leslie Daigle
> Sent: 05 November 2009 06:06
> To: re-ecn@ietf.org
> Subject: [re-ECN] Viability issue #1
> 
> 
> [This attempts to outline an issue that could be perceived as
> challenging the viability of congestion exposure work.  The goal is to
> capture the issue, as well as itemize reasonable supporting arguments
> (for viability) and remaining questions to be addressed.  Please
> respond
> with suggestions as needed for each section.  ]
> 
> 
> Viability Issue #1
> 
> What are the points in favour of/against congestion exposure as an
> architecturally sound technique to specify for the Internet?  (NB --
> this is about congestion exposure, as constrained in the agreed
> principles, not any particular proposal)?
> 
> Suggested:
> 
> 1/ This is about network flows, not applications or services, so it
> will
> serve future network uses (application types).

I would go further and say this is even about single packets in
isolation. Allowing each packet to inform the network of the cost (in
resources, not money) of conveying it to the destination


> 
> 2/ Congestion exposure provides mechanisms to declare awareness of
> whole-path congestion WITHOUT prescribing behaviours.

Yes, and more to the point almost any behaviour you wanted could be
built on top of congestion exposure...

> 
> 3/ This is also network agnostic in the sense that no pre-existing
> agreements or interpretations need be in place to make the congestion
> exposure work.  (*Accounting* for it is a separate matter, but that's
> okay).

As long as this is specified in such a manner that middleboxes are able
to transparently forward the correct information then this is true


> 
> 
> Questions:
> 
> 4/ To what extent is this dependent on an assumed network architecture
> where the major sources of content (and congestion) traverse transit
> networks, as opposed to being CDNs connected directly to access
> networks
> (for business purposes)?

Even if they are CDNs they are still going to potentially cause
congestion that someone may need to account for. Indeed many people
suggest most congestion is in the access... Congestion exposure is NOT
just about inter-network agreements. It also works intra-network
(imagine a company being able to relax their rules on network access
during working hours as long as their employees ensured they never
caused excessive congestion that might impact business-needs use of the
network).

> 
> 
> 
> --
> 
> -------------------------------------------------------------------
> "Reality:
>       Yours to discover."
>                                  -- ThinkingCat
> Leslie Daigle
> leslie@thinkingcat.com
> -------------------------------------------------------------------
> _______________________________________________
> re-ECN mailing list
> re-ECN@ietf.org
> https://www.ietf.org/mailman/listinfo/re-ecn