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

["David R. Oran" <[e-mail]>]

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