Re: [conex] Potentially interesting ConEx problem

John Leslie <john@jlc.net> Tue, 05 March 2013 18:12 UTC

Return-Path: <john@jlc.net>
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 4997F21F8651 for <conex@ietfa.amsl.com>; Tue, 5 Mar 2013 10:12:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.949
X-Spam-Level:
X-Spam-Status: No, score=-105.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 IfzoTWV0AQOm for <conex@ietfa.amsl.com>; Tue, 5 Mar 2013 10:12:28 -0800 (PST)
Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id B94BD21F8639 for <conex@ietf.org>; Tue, 5 Mar 2013 10:12:28 -0800 (PST)
Received: by mailhost.jlc.net (Postfix, from userid 104) id CC4C433C21; Tue, 5 Mar 2013 13:12:28 -0500 (EST)
Date: Tue, 05 Mar 2013 13:12:28 -0500
From: John Leslie <john@jlc.net>
To: Matt Mathis <mattmathis@google.com>
Message-ID: <20130305181228.GN84856@verdi>
References: <CAH56bmD5c3KjVxg3gf9utBTQDLQS3HnxjVbpYf1Bby=iOB85bQ@mail.gmail.com> <201303050953.r259rCTS000573@bagheera.jungle.bt.co.uk> <CAH56bmAn5MzD8UVAXKEoQf-kWdeyM-08QM9mxUT0pLDyx4xVDA@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAH56bmAn5MzD8UVAXKEoQf-kWdeyM-08QM9mxUT0pLDyx4xVDA@mail.gmail.com>
User-Agent: Mutt/1.4.1i
Cc: ConEx IETF list <conex@ietf.org>
Subject: Re: [conex] Potentially interesting ConEx problem
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, 05 Mar 2013 18:12:29 -0000

Matt Mathis <mattmathis@google.com> wrote:
> 
> A large content provider might, for example, want to be able to
> distinguish between appropriately filling subscriber links and
> aggravating some capacity failure elsewhere along the path.
> Traditional serving optimizations actually make this problem far
> worse: serving from as many places as possible, as close to the users
> as possible makes the system even more brittle to ISP failures.

   It sounds as if Matt could make use of a hop-count recorded by an
ECN-aware node experiencing a loss in the ConEx Destination Option.
(I'd rather hear from Matt whether that could work _before_ hearing
from others why it's a ReallyBadIdea...)

--
John Leslie <john@jlc.net>