[rmcat] requirements (was Re: time to get active)

ken carlberg <carlberg@g11.org.uk> Wed, 27 February 2013 19:13 UTC

Return-Path: <carlberg@g11.org.uk>
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C30521F84C8 for <rmcat@ietfa.amsl.com>; Wed, 27 Feb 2013 11:13:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.339
X-Spam-Level:
X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3VxVteFxjXg for <rmcat@ietfa.amsl.com>; Wed, 27 Feb 2013 11:13:18 -0800 (PST)
Received: from portland.eukhosting.net (portland.eukhosting.net [92.48.97.5]) by ietfa.amsl.com (Postfix) with ESMTP id 3536B21F8499 for <rmcat@ietf.org>; Wed, 27 Feb 2013 11:13:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=g11.org.uk; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=kPNO5WOIwA3c7vK8PZwnV788WHDZ+0YG1GBbDJrnWSg=; b=P0ny+xl4UJRBC6LAC6+PINrmPxhhSF94Ounf8YScS/sWQq+8wOE03Mi752WKULc0msLYJKshzdKw6cax+tYGkIBv1Ltie+8VfT9SZomMJHswVPzupleBKr4aHn5lHiko;
Received: from c-98-218-170-72.hsd1.va.comcast.net ([98.218.170.72]:39500 helo=[10.0.1.20]) by portland.eukhosting.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from <carlberg@g11.org.uk>) id 1UAmRE-003YYU-Cf; Wed, 27 Feb 2013 19:13:12 +0000
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: ken carlberg <carlberg@g11.org.uk>
In-Reply-To: <D4D47BCFFE5A004F95D707546AC0D7E91F7690F6@SACEXCMBX01-PRD.hq.netapp.com>
Date: Wed, 27 Feb 2013 14:13:11 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <023D88F2-1A6E-47C2-91B2-8B56DEEC70B1@g11.org.uk>
References: <D4D47BCFFE5A004F95D707546AC0D7E91F768E66@SACEXCMBX01-PRD.hq.netapp.com> <CAH56bmDCaQB3fQLq4UyiEWY2_qEhHXzp7aoyqde5K=rMZcLKvg@mail.gmail.com> <D4D47BCFFE5A004F95D707546AC0D7E91F7690F6@SACEXCMBX01-PRD.hq.netapp.com>
To: "Eggert, Lars" <lars@netapp.com>
X-Mailer: Apple Mail (2.1499)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - portland.eukhosting.net
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - g11.org.uk
X-Get-Message-Sender-Via: portland.eukhosting.net: acl_c_relayhosts_text_entry: carlberg@g11.org.uk|g11.org.uk
Cc: rmcat WG <rmcat@ietf.org>, Matt Mathis <mattmathis@google.com>
Subject: [rmcat] requirements (was Re: time to get active)
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." <rmcat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rmcat>, <mailto:rmcat-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rmcat>
List-Post: <mailto:rmcat@ietf.org>
List-Help: <mailto:rmcat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rmcat>, <mailto:rmcat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Feb 2013 19:13:19 -0000

well, perhaps I can get the ball rolling in terms of a headache to chew on :-)

The second requirement in draft-jesup-rmcat-reqs-01.txt is...

  2.   The algorithm must be fair to other flows, both realtime flows
        (such as other instances of itself), and TCP flows, both long-
        lived and bursts such as the traffic generated by a typical web
        browsing session.  Note that 'fair' is a rather hard-to-define
        term.

        A.  The algorithm must not overreact to short-term bursts (such
            as web-browsing) which can quickly saturate a local-
            bottleneck router or link, but also clear quickly, and
            should recover quickly when the burst ends.

        B.  We will need make some evaluation of fairness, but deciding
            what is "fair" is a tough question and likely to be
            partially subjective, but we should specify some of the
            inputs needed in order to select among algorithms and
            tunings presented as options.

however, the document does not have a definition of the term "fair" or "fairness".  And while the document points us to terminology in another draft (draft-ietf-rtcweb-overview-06.txt), this other draft doesn't even mention "fair" or fairness".  I think one nit is that the RMCAT requirements draft needs its own terminology section instead of pointing to another draft.

And more importantly, I think we need to bite the bullet and decide what is "fair" / "fairness".  It just doesn't seem possible for us to say that the algorithms *must* be fair, but then punt in defining what is (or perhaps, what is not) fair.  And I'm definitely not meaning to beat up on the author, but rather ourselves.

As a starting point, and in the context of real time apps, I don't think we need to be fair to a continual series of parallel short transaction flows.  Rather, I would prefer to be fair, or focus our attention, to longer transaction flows.

thoughts?  Have I missed something?

-ken



On Feb 27, 2013, at 1:37 PM, "Eggert, Lars" <lars@netapp.com> wrote:

> On Feb 27, 2013, at 19:35, Matt Mathis <mattmathis@google.com> wrote:
>> Did we perhaps address all of the hard problems in the charter process, so
>> now there is nothing to controversial to chew on?
> 
> I wish...
> 
> Lars