Re: [re-ECN] RE-ECN without ECN.
Matt Mathis <matt.mathis@gmail.com> Mon, 05 October 2009 21:43 UTC
Return-Path: <matt.mathis@gmail.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 87FA53A698B for <re-ecn@core3.amsl.com>;
Mon, 5 Oct 2009 14:43:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.56
X-Spam-Level:
X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039,
BAYES_00=-2.599]
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 qQHhq1BX5Ghz for
<re-ecn@core3.amsl.com>; Mon, 5 Oct 2009 14:43:31 -0700 (PDT)
Received: from mail-bw0-f210.google.com (mail-bw0-f210.google.com
[209.85.218.210]) by core3.amsl.com (Postfix) with ESMTP id 66DA03A6407 for
<re-ecn@ietf.org>; Mon, 5 Oct 2009 14:43:31 -0700 (PDT)
Received: by bwz6 with SMTP id 6so2842301bwz.37 for <re-ecn@ietf.org>;
Mon, 05 Oct 2009 14:45:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
h=domainkey-signature:mime-version:received:in-reply-to:references
:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding;
bh=yQeA+Oj2KmmXX9fd3h4HBm16Ft/DJN4LMX/w6u6bzSM=;
b=p6Qh2GaAAtzUmi/uWTqtpIhPGyTfUdWGgJM3vutTKbjF0EB1Ce7HPoFDaBqJ5Z//re
P/Bo7GT10WXODoo60/IPqv3qIw5qhw1+rBluVSOfwJMzilXlfIYwojo06dWIIyUgKYx1
XeST1vAXARiWL8ZpGMzdAk+2aSfz7yjJV4Igc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type:content-transfer-encoding;
b=T588ezoYzqWqmsF9sL6q3snlS7Ssmg6yQUXdbNf5PcnZ/WKQ2cHiRxNyhH8gGjDsfK
g+p84Atovbnc1OsOjIGg1In0+C8WI5IQpahUNlvDcr+Z8tqQlqIqnsI1mR46aF2EV3g4
oWaEHOCVwNTceLXiHUhl1GHEFUQ1fb7/wYscM=
MIME-Version: 1.0
Received: by 10.204.156.205 with SMTP id y13mr4459873bkw.116.1254779103972;
Mon, 05 Oct 2009 14:45:03 -0700 (PDT)
In-Reply-To: <3558451F-5A22-4E76-B2AA-A38026ECC969@cisco.com>
References: <fc0ff13d0910010936i5aa26e6esd830c958422e340d@mail.gmail.com>
<3558451F-5A22-4E76-B2AA-A38026ECC969@cisco.com>
Date: Mon, 5 Oct 2009 17:45:03 -0400
Message-ID: <fc0ff13d0910051445s62397c5co6b2e2de94268e20e@mail.gmail.com>
From: Matt Mathis <matt.mathis@gmail.com>
To: Fred Baker <fred@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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: Mon, 05 Oct 2009 21:43:37 -0000
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. Reordering is not insurmountable. Network reordering is most often bound by some fairly small maximum offset related to the number of parallel paths or processing stripes. Retransmissions are always out-of-order by slightly more than one full window of data. At small window/low rates these are indistinguishable, but it probably isn't as important to get it right. At higher rates, these are likely to be different by an order of magnitude or more. My hunch would be that a pretty simple adaptive controller might do well enough. Yes, more research is needed. > I personally am very much in favor of congestion signaling that doesn't > involve loss, and supported the development of RFC 3168 as a result. I > scratch my head on re-ecn - not opposed per se, but noting that there are > issues with any traffic in which the flags may not be visible - tunnels > especially come to mind - and in asking the first hop router to do > something. What is a "first hop router"? Is it the CPE router, such as > Linksys-etc, or the first ISP hop, or something else? 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). Thanks, --MM-- ------------------------------------------- Matt Mathis http://staff.psc.edu/mathis Work:412.268.3319 Home/Cell:412.654.7529 ------------------------------------------- Evil is defined by mortals who think they know "The Truth" and use force to apply it to others.
- [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