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.