Re: [re-ECN] RE-ECN without ECN.
"Don Bowman" <don@sandvine.com> Tue, 06 October 2009 02:27 UTC
Return-Path: <don@sandvine.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 03DC83A688C for <re-ecn@core3.amsl.com>;
Mon, 5 Oct 2009 19:27:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.855
X-Spam-Level:
X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=-0.745,
BAYES_05=-1.11]
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 W-2YTku6k1a3 for
<re-ecn@core3.amsl.com>; Mon, 5 Oct 2009 19:27:01 -0700 (PDT)
Received: from mail2.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by
core3.amsl.com (Postfix) with ESMTP id 1BFCF3A680F for <re-ecn@ietf.org>;
Mon, 5 Oct 2009 19:27:00 -0700 (PDT)
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: Mon, 5 Oct 2009 22:22:06 -0400
Message-ID: <EB618291F3454E4DA10D152B9045C0170215E167@exchange-2.sandvine.com>
In-Reply-To: <fc0ff13d0910051445s62397c5co6b2e2de94268e20e@mail.gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [re-ECN] RE-ECN without ECN.
Thread-Index: AcpGBSBYdvjFQulLRAKkvQWRHAlpLAAIKfhA
References: <fc0ff13d0910010936i5aa26e6esd830c958422e340d@mail.gmail.com><3558451F-5A22-4E76-B2AA-A38026ECC969@cisco.com>
<fc0ff13d0910051445s62397c5co6b2e2de94268e20e@mail.gmail.com>
From: "Don Bowman" <don@sandvine.com>
To: "Matt Mathis" <matt.mathis@gmail.com>, "Fred Baker" <fred@cisco.com>
Cc: re-ecn@ietf.org
Subject: Re: [re-ECN] RE-ECN without ECN.
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: Tue, 06 Oct 2009 02:27:02 -0000
On Mon, Oct 5, 2009 at 5.45 PM, Matt Mathis wrote: > On Mon, Oct 5, 2009 at 3:03 PM, Fred Baker <fred@cisco.com> wrote: > > > > On Oct 1, 2009, at 9:36 AM, Matt Mathis wrote: > > > >> If you add the assumption that the network itself does not reorder > >> packets, then the number of out-of-order packets is a direct measure > >> of the upstream congestion. (e.g. the first transmission was lost, > >> and I see the retransmission). > > > > The assumption concerns me. There are probably places in the Internet > where > > loss is unusual and reordering is unusual, but making it a baseline > > assumption... The Internet is still a best effort service, which is > to say > > that datagrams may be lost, duplicated, or reordered. One thing to watch out for is hand-off conditions. E.g. in a mobile network, handing from one cell to another, or one carrier to another, can cause some re-ordering w/o loss. Also, periodically you run into a network which balances by packet rather than flow, or balances by flow on something which isn't stable and flops back and forth. Typically OSPF ECMP does a L3(or L4) hash to select a link, but sometimes that hash is of an 'outer' ip which is not relevant to the inner content, and thus reordering occurs. ... snip ... > > I agree all around. Bob has been putting a lot of effort into making > sure that the specifications for tunnels say the right things. What > I don't know is if there have been any measurements of the population > of devices that do busted things, such not updating the inner ECN bits > from the outer header on decapsulation. (But note that this is > busted for all variants of ECN). Again to the mobile network. One of the most (variably) congested networks out there is the mobile backhaul network. In 3GPP, this is carried in a tunnel type called GTP-U. I've not found GTP-U implementations to be much for moving markings from outer to inner (e.g. DSCP). I've done a quick check on a couple of networks, and did not observe ECN marked on the inner, so i can't say if they support ECN 'moving the mark'. One of the things i am hopeful to use re-ECN for in our products is as an indication of backhaul health (and i dream someday of RF health) so that we can break reporting information down by 'this is what congested/near-congested/non-congested links are doing'. So i'm hopeful it can be made to work in GTP-U (which implies getting ECN basis working). --don
- [re-ECN] RE-ECN without ECN. Matt Mathis
- Re: [re-ECN] RE-ECN without ECN. João Taveira Araújo
- Re: [re-ECN] RE-ECN without ECN. Bob Briscoe
- Re: [re-ECN] RE-ECN without ECN. Matt Mathis
- Re: [re-ECN] RE-ECN without ECN. João Taveira Araújo
- Re: [re-ECN] RE-ECN without ECN. Fred Baker
- Re: [re-ECN] RE-ECN without ECN. Fred Baker
- Re: [re-ECN] RE-ECN without ECN. Matt Mathis
- Re: [re-ECN] RE-ECN without ECN. Matt Mathis
- Re: [re-ECN] RE-ECN without ECN. Fred Baker
- Re: [re-ECN] RE-ECN without ECN. Bob Briscoe
- Re: [re-ECN] RE-ECN without ECN. Don Bowman
- Re: [re-ECN] RE-ECN without ECN. philip.eardley