Re: [icnrg] Last Call: draft-oran-icnrg-qosarch

"Dirk Kutscher" <ietf@dkutscher.net> Tue, 11 February 2020 11:05 UTC

Return-Path: <ietf@dkutscher.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 BE0C112007C for <icnrg@ietfa.amsl.com>; Tue, 11 Feb 2020 03:05:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 qxUZ2YG6rJvb for <icnrg@ietfa.amsl.com>; Tue, 11 Feb 2020 03:05:21 -0800 (PST)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D0D212007A for <icnrg@irtf.org>; Tue, 11 Feb 2020 03:05:20 -0800 (PST)
Received: from [192.168.1.69] ([77.21.26.148]) by mrelayeu.kundenserver.de (mreue012 [212.227.15.167]) with ESMTPSA (Nemesis) id 1M3VAI-1j0vJB0Iyo-000dbe; Tue, 11 Feb 2020 12:00:11 +0100
From: Dirk Kutscher <ietf@dkutscher.net>
To: Colin Perkins <csp@csperkins.org>
Cc: ICNRG <icnrg@irtf.org>
Date: Tue, 11 Feb 2020 12:00:10 +0100
X-Mailer: MailMate (1.13.1r5671)
Message-ID: <56D947E2-9A9F-4B93-A2FC-70A53BB7466C@dkutscher.net>
In-Reply-To: <9BCFBA67-509A-41BD-8351-334AF844C5F5@csperkins.org>
References: <E35749ED-CFB8-4352-BE66-724BC2C49B64@dkutscher.net> <9BCFBA67-509A-41BD-8351-334AF844C5F5@csperkins.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K1:Y/lwxiVucLInnRaH5AkKX8zzox7UaQq6228elKauiUtR9KfN04c ip1i6n66rQiNN5S7gyjjaT3kcKBVaeyoyeAuZPwKvaWcT6/O3lG0XrJrMMwAvUxL/KGP9gg 9P801iBnKDVA6aA/alueuLsFNVpsVK3nSgSDpBiOC5h38wVeqXsHcoXqTl38n3Desgt+s/h LAKolF+dnMXnmkgf/JEiQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:7Dg3AhWV+B0=:BS2++K/jTC9lh5WkvcOB8Y EnlKfUnzgF9dgzX3u+g/paah1kQEGnt91P1fB/qw77G9LWcRiffayXwsmtZKr/GJhWdBOhFoW XO9jmh4GGqjVc52+DusrNSbr2T+yzF8375DUo84V4GT6rsTpfIlI5Lt29MvIuw504T+2E7OPf 9kENxMOwyb2qnJ6gQf75/Yzi0bM+KMBaf5noSm8gqaTGaiOzZuZLTzltYUc1z3Dk7pxhwO1w8 g3u3EBJVlTK1eLPoCSCnJDVVMQ77+LTwDlRpIpqAV1EmidgLxQG0CAZRxrsprIHipOZTAPuvk 6pMWJYlJq6eSD+odMt0Vv5tA/XeZTS8NZI8u5BiWHnRXzLt2U7AAnBd1JiDZaKgqCnsHzEZRB yv8YQA0h6aPCAo34QOPKyWhCVDx1ArsWZfAxAc0HijwKGzLS5Y/hqNpqSTp2sLA+uPsi8QbKx GpUc4NPM5Nn1Bq9GEF8d6ULuqpmn78EFJfuWbPMVunZOGZBb4r0LRyXnQ4CWQ/2jW2oebRi7F Etgeyy+P9QBYVYwQ/Zh2MD2YBPf41/hV0K2OxC5vK9j2iaCrzb5ihTf5ktmGiLk3t1nxJC2ma p+CmXEOfhE/cQJHzHHEkeju7swSyAM1WEmfggscSFG2g2jg8ngOz//3qJJeNtZqm2voiJ6By/ cVKDWO4SCtDTXc7vm2HWl5N/nqfZkvuV4IJScwpgaIgufpnx07fHXYBB0pzvEvtPdJXA36VjQ zxQ64Mcq+i3U8btE4lI4FJ53+Br5vE57wLptzcFKZEBaIgcxNPDTrXsJFZcOWBomLHTCbxUm+ k0bMlq5kVMq4htTmHKERZ9go1mLXCvkJcY5ql/WG4QueWCipgyd3Vx6i7NMNG7mkwReQkCY
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/CsCuU8yupVaZXO-1ApgVf7x2ZT0>
Subject: Re: [icnrg] Last Call: draft-oran-icnrg-qosarch
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: Tue, 11 Feb 2020 11:05:24 -0000

Thanks, Colin.

> I think it’s reasonable to publish this as a position paper, 
> provided the RG is okay with that, but would it be possible to add a 
> few words to the Introduction to explain why the ICN RG thinks this is 
> best published as a position paper? (To be clear that the points in 
> RFC 5743 Section 2.1 are explicitly addressed)

Yes, let’s do that. I will draft some lines from an ICNRG perspective 
that Dave could consider including here.

> Also, the short title (“ICN QoS Architecture”) on each page can be 
> read as perhaps implying a stronger status than intended. Is there 
> space to change it to something like “Proposed ICN QoS 
> Architecture” instead?

Yes, good point. Dave already noted that “ICN QoS Architecture 
Considerations” (or something in that direction) is more appropriate 
and will change the draft accordingly.

Again, the last call period for this draft is over. If people have other 
comments, please share them now. We will move to IRSG review when the 
new version is ready.

Thanks,
Dirk



> Colin
>
>
>
>
>> We (Dave as the author, and Börje & myself as chairs) think that the 
>> draft is useful and mature enough so that we can move it towards 
>> publication, and I would therefore like to last-call it. Please read 
>> it and let us know if you think there are issues. The last call ends 
>> on February 7th, i.e., 2.5 weeks from today.
>>
>>
>> https://datatracker.ietf.org/doc/draft-oran-icnrg-qosarch/
>>
>> Abstract
>>
>>   This is a position paper.  It documents the author's personal views
>>   on how Quality of Service (QoS) capabilities ought to be 
>> accommodated
>>   in ICN protocols like CCNx or NDN which employ flow-balanced
>>   Interest/Data exchanges and hop-by-hop forwarding state as their
>>   fundamental machinery.  It argues that such protocols demand a
>>   substantially different approach to QoS from that taken in TCP/IP,
>>   and proposes specific design patterns to achieve both 
>> classification
>>   and differentiated QoS treatment on both a flow and aggregate 
>> basis.
>>   It also considers the effect of caches as a resource in addition to
>>   memory, CPU and link bandwidth that should be subject to explicitly
>>   unfair resource allocation.  The proposed methods are intended to
>>   operate purely at the network layer, providing the primitives 
>> needed
>>   to achieve both transport and higher layer QoS objectives.  It
>>   explicitly excludes any discussion of Quality of Experience (QoE)
>>   which can only be assessed and controlled at the application layer 
>> or
>>   above.
>>
>> Best regards,
>> Dirk
>>
>> _______________________________________________
>> icnrg mailing list
>> icnrg@irtf.org
>> https://www.irtf.org/mailman/listinfo/icnrg
>
>
>
> -- 
> Colin Perkins
> https://csperkins.org/
>
>
>
>
> _______________________________________________
> icnrg mailing list
> icnrg@irtf.org
> https://www.irtf.org/mailman/listinfo/icnrg