Re: [icnrg] [irsg] IRSG ballot closed: <draft-oran-icnrg-qosarch-05.txt> to Informational RFC

"David R. Oran" <daveoran@orandom.net> Fri, 06 November 2020 16:05 UTC

Return-Path: <daveoran@orandom.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 B657B3A07D3; Fri, 6 Nov 2020 08:05:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 qxMYHZrvdj_2; Fri, 6 Nov 2020 08:05:09 -0800 (PST)
Received: from spark.crystalorb.net (spark.crystalorb.net [IPv6:2607:fca8:1530::c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8733C3A07C4; Fri, 6 Nov 2020 08:05:09 -0800 (PST)
Received: from [192.168.15.243] ([IPv6:2601:184:407f:80ce:951a:fb59:5d77:762f]) (authenticated bits=0) by spark.crystalorb.net (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id 0A6G540r007444 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Fri, 6 Nov 2020 08:05:06 -0800
From: "David R. Oran" <daveoran@orandom.net>
To: "Mallory Knodel" <mknodel@cdt.org>
Cc: "The IRSG" <irsg@irtf.org>, irtf-chair@irtf.org, icnrg@irtf.org, draft-oran-icnrg-qosarch@ietf.org, icnrg-chairs@ietf.org
Date: Fri, 06 Nov 2020 11:04:58 -0500
X-Mailer: MailMate (1.13.2r5726)
Message-ID: <6C203090-951D-4836-9329-CC74473C8A94@orandom.net>
In-Reply-To: <4d45321f-af31-05bd-0576-79ca007a8a67@cdt.org>
References: <160250569271.3121.5927073982280689228@ietfa.amsl.com> <09227BB5-37F6-42C2-8971-0E6E53FA6A44@orandom.net> <4d45321f-af31-05bd-0576-79ca007a8a67@cdt.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_613EEBA9-FC52-4B16-A1EC-7BAE03C597CE_="
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/Zm-7tWwXrAzO-w7tOZlbOCI2yJE>
Subject: Re: [icnrg] [irsg] IRSG ballot closed: <draft-oran-icnrg-qosarch-05.txt> to Informational RFC
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: Fri, 06 Nov 2020 16:05:12 -0000

Snipping out all but the one comment from Mallory that I’d like to 
address.

On 6 Nov 2020, at 10:25, Mallory Knodel wrote:

>>   Mallory’s comment:
>>
>> |“The draft includes a lot of meta narrative about the discussion 
>> of the draft and unresolved issues in the IRSG without simply 
>> resolving those issues and presenting the research as a whole. 
>> Furthermore the "managed unfairness" framing sets a low bar when QoS 
>> should be primarily about defining the high bar. While it might be 
>> worth mapping the floor, I suggest it's real value for the IRTF would 
>> be achieved in conjunction with finding the ceiling.” |
>>

>> On the comment about setting a “low bar”, I respectfully disagree 
>> with Mallory’s assessment. Perhaps there’s just a 
>> mis-communication, since I view QoS as a zero-sum game and therefore 
>> there’s neither a high bar nor a low bar where QoS machinery is 
>> concerned. I’d definitely be interested in trying to get to the 
>> bottom of where Mallory thinks the draft falls short in proposing a 
>> general direction for QoS architecture for ICN protocols.
>>
> If it's a zero-sum then "managed unfairness" is equal to "managed 
> fairness". It's a choice, like glass half full or half empty, to 
> present to the recipient of the service to expect unfairness, like 
> everyone else, rather than present these mechanisms as attempting to 
> optimise QoS decisions to be most fair, no?
>
I choose the “half-empty formulation for two reasons:

1. This is a semi-famous formulation due to Van Jacobson which 
emphasizes the “no free lunch” aspect of QoS machinery.

2. One could use a different, broader definition of QoS that encompasses 
optimizing the allocation of network resources across all offered 
traffic without considering individual users’ traffic (hence being 
“fair” under one of the common definitions) and how those offered 
traffic subsets relate to one another. This would then be a document 
that tried to cover whether (and how) ICN might result in better overall 
performance than IP under constant resource conditions. That’s a way 
bigger scope. I would defend my scope by saying it comports with the 
commonly understood meaning of “QoS” in the research community. 
Under that scope, and under constant resource constraints, the only way 
to provide traffic discrimination is in fact to sacrifice fairness.

Does that put your mind at ease, or do you think some further text would 
help justify why I cast the problem the way I do?

Thanks again for the comments!


> -Mallory
>
> -- 
> Mallory Knodel
> CTO, Center for Democracy and Technology
> gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780


DaveO