Re: [icnrg] Some background on draft-oran-icnrg-flowbalance-00.txt

"Naveen Nathan" <icnrg@t.lastninja.net> Sun, 04 August 2019 06:37 UTC

Return-Path: <icnrg@t.lastninja.net>
X-Original-To: icnrg@ietfa.amsl.com
Delivered-To: icnrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83C1012002F for <icnrg@ietfa.amsl.com>; Sat, 3 Aug 2019 23:37:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=t.lastninja.net header.b=I5N42570; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=JQHWdAXw
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5KPnDilaYbI for <icnrg@ietfa.amsl.com>; Sat, 3 Aug 2019 23:37:15 -0700 (PDT)
Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9688612001A for <icnrg@irtf.org>; Sat, 3 Aug 2019 23:37:15 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id EA653358 for <icnrg@irtf.org>; Sun, 4 Aug 2019 02:37:14 -0400 (EDT)
Received: from imap8 ([10.202.2.58]) by compute6.internal (MEProxy); Sun, 04 Aug 2019 02:37:15 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=t.lastninja.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm3; bh=lD/Iu f5I/6HPAZmFh2j8qOQ3D17+eL8P7AclzfOJjAM=; b=I5N42570hc5Dyk1GfSp3+ LBTNEC7mlSKDg9WJRoGvDhcs/TDZ1YqXbP8oqZ4C3/i9tjKxoluVRpnPODEw0CSD U2gReLT4o77kdoelIbkR1fuNTm3pfQsLpJzjIld200c+RbeHgmHqtz2GWuKY3voZ p0Jm1/b+jqRllLl50Bmdqp97T/Rr+0GNpaktzG8UD0Z1lHQjRJjB1ZQ2le31BR2L xP5xmen1Xo+yebU5xQW8mG+IIsAH92pSKiwOOWsrzIFA6IYhNYc7WvQz2kSWUeXM EqJ0UoWlzuoRtf/GXhnIGzuxWlLL56sZ2W1Shy3Htda+Io/GJKDT8AqE3ljyMw4A g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=lD/Iuf5I/6HPAZmFh2j8qOQ3D17+eL8P7AclzfOJj AM=; b=JQHWdAXw5oDrhR39xBCV947t3kfjr7+SaHznm8Qxa1o2UopriRohc/+Xj COBWzHozaXQdusSDUTFtVXFu1MwJ1yXl6aAnB9WTvIbtl3UtFkGtGgOI17IXZvyF M2QasCaNdYM3GhshAgwXbFctAk317HsdHcfHyGGeNm/wRj+XIfWHm8Efj3JjdJHv lUmM2WgINr4SkS2lWqp/t17zDgZm0dgboPCasQnI+iR1N/tZFxnXubiwjnWtdxjB NApGhZYXOFPhk6tBTBAcll6P7zT1bXPbJ2RAepVykcwuOfZV67/eZEoNuhpXHZFO y38J/rvV9romjgf3YvzxqzGuCZ6xg==
X-ME-Sender: <xms:Gn1GXQf0F5QRd01rx7dnzVwBinRnoEaNw_XZYGNvus7iWigLZNtGnA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddruddtgedgudehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdfprghvvggvnhcupfgrthhhrghnfdcuoehitghnrhhg sehtrdhlrghsthhnihhnjhgrrdhnvghtqeenucfrrghrrghmpehmrghilhhfrhhomhepih gtnhhrghesthdrlhgrshhtnhhinhhjrgdrnhgvthenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:Gn1GXXc65KrRB1oAarour1yGmB_WYyh1N0NkT3bQiybCPb6lc2Tyfg> <xmx:Gn1GXTNu-79oiVT_ByEc0LRqfJ8PWDZHGDuLwS8G4-LhO3DSjYtm0A> <xmx:Gn1GXeKzXKiVDkCqDXN8VPzcQ9wdpsn-fAJX7bh4Uqfy4Ys-yzKFhA> <xmx:Gn1GXS9ifFXp5zGhzXkfLtHqG6rSWIEEfUO_1fyfelBwHtFuS7aS9A>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0F5DE520093; Sun, 4 Aug 2019 02:37:14 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.6-799-g925e343-fmstable-20190729v1
Mime-Version: 1.0
Message-Id: <bec78d84-7f95-4f26-a27d-e91ed174cba0@www.fastmail.com>
In-Reply-To: <CFF08899-6D27-4949-9DC3-35C73810F6E2@orandom.net>
References: <F3450525-2EDB-4AB3-8909-3EB55F6245C4@orandom.net> <1f023920-4a17-4335-b5fe-ef90b68e113c@www.fastmail.com> <CFF08899-6D27-4949-9DC3-35C73810F6E2@orandom.net>
Date: Sun, 04 Aug 2019 16:37:13 +1000
From: "Naveen Nathan" <icnrg@t.lastninja.net>
To: icnrg@irtf.org
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/xNCXoL9ZqZqnuLStY_bo-WD7Wik>
Subject: Re: [icnrg] Some background on draft-oran-icnrg-flowbalance-00.txt
X-BeenThere: icnrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Information-Centric Networking research group discussion list <icnrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/icnrg>, <mailto:icnrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/icnrg/>
List-Post: <mailto:icnrg@irtf.org>
List-Help: <mailto:icnrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/icnrg>, <mailto:icnrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sun, 04 Aug 2019 06:37:18 -0000

See responses below.

- Naveen

On Sun, 4 Aug 2019, at 12:08 AM, David R. Oran wrote:
> > [...]
> > Regarding the consumer under-estimating (i.e. too big objects), I 
> > think it
> > might be good to elaborate on a different dimension such a lossy 
> > versus
> > lossless protocols. E.g. video streaming can deal with a loss of a 
> > large
> > object, and be informed of what to request in subsequent chunks. But 
> > this can
> > get tricky with VBR style encoding. But perhaps this is actually a bad 
> > example
> > since most video stream will use a manifest mechanism so requests 
> > would have
> > accurate estimates.
> >
> The issue here isn’t the loss, since any dynamic congestion control 
> algorithm will either wind up under-allocating bottleneck links by a 
> large fraction, or occasionally allow buffers to overflow and drop 
> packets. I didn’t put much of a tutorial on basic congestion control 
> in the document since the reader is assumed familiar with the cited 
> references. What may be worth reiterating is that even congestion 
> control algorithm has an explicit fairness goal and associated objective 
> function (usually either min-max fairness or proportional fairness). If 
> your fairness is to be based on resource usage, pure interest counting 
> doesn’t do the trick, since a consumer asking for large thing can 
> saturate a link and shift loss to consumers asking for small things.
> 
> Does that make sense? Should the document say more about this?

Yes, and yes.

So I think the congestion control algorithm (and knowledge these
algorithms lack) is sufficiently explained in section 3. I think you should
incorporate the point you made about fairness in the above response
in section 3 as well.

> > I also think you should mention that this mechanism can be used to 
> > inform a
> > congestion control algorithm. I do note that this is explicitly 
> > mentioned in
> > section 3.
> >
> Hmmm, maybe I need to be more direct?

Yes. But I forgot to say earlier that it should be mentioned in the end
of section 1 (the introduction).

> > About section 3.4. where you describe interest aggregation. You 
> > recommend the
> > second policy of giving a large object to correctly/over-estimating 
> > consumers,
> > whereas underestimating consumers get T_MTU_TOO_LARGE (also does "MTU" 
> > make
> > sense instead of "REQUEST"?). Shouldn't all consumers get it, if the 
> > link isn't
> > congested? I think this T_MTU_TOO_LARGE should only be sent if there's
> > contention on the link and insufficient bandwidth can be allocated.
> >
> That’s of course a possibility. I decided recommending the error for 
> the following reasons (which perhaps ought to be explicitly stated in 
> the spec):
> 1. The link can be congested quite quickly after the queuing decision is 
> made, especially if the data has a long link-occupancy time, so this is 
> a safer alternative.
> 2. The cost of returning the error is only one link RTT, since the 
> consumer can immediately re-issue the interest with the correct size and 
> pick up the cached object from the upstream forwarder’s CS.
> 3. I tried to completely avoid the issues of aggregate resource control 
> and the associated billing swamp, since returning the data raises the 
> messy issue of whether to “charge” the actual used bandwidth to the 
> consumer, or only the requested bandwidth through the expected data 
> size. The rabbit hole goes deeper if you add differential QoS to the 
> equation (another subject intentioanally not talked about in the 
> document for many reasons) as consumers “playing games” and 
> intentionally underestimating so their interests get satisfied when 
> links aren’t congested gets you into all the considerations of 
> malicious actors discussed later.

I think it should be explicitly stated since intuitively if you have the
resources to send the data to the client, you would. But this is going
against the grain for the above reasons you stated.