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

From: Colin Perkins <[email-masked]>
Date: Sun, 9 Feb 2020 23:17:49 +0000

Dirk,

> On 21 Jan 2020, at 19:47, Dirk Kutscher <[email-masked]> wrote:
> 
> In Singapore, we mentioned that we would eventually like to publish draft-oran-icnrg-qosarch and after a discussion with the IRTF chair concluded that, given the nature of this document, the best way would be to treat it as a position paper and publish it as an Informational RFC without adopting it as an RG item.
> 
> The motivation is that this document, instead of specifying a specific architecture or mechanism, is rather illustrating a certain direction (that may or may not inform future specific QoS work in ICNRG).

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)

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?

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
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg

-- 
Colin Perkins
https://csperkins.org/

---

From: "Dirk Kutscher" <[email-masked]>
Date: Tue, 11 Feb 2020 12:00:10 +0100

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.
>>
>>

---

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 11 Feb 2020 20:22:00 +0900

Hi,

Sorry for the late response.
I have no concern about moving this forward, yet suggest to consider one thing.

For the effective use of in-network cache, network coding is also helpful to improve the data transmission quality. I therefore recommend to add some statement explaining the way of its use or adoption with some references already discussing the advantages (or even difficulties) for ICN. 

Regards,

Hitoshi

> On Feb 11, 2020, at 20:00, Dirk Kutscher <[email-masked]> wrote:
> 
> Thanks, Colin.
> 
> Yes, let’s do that. I will draft some lines from an ICNRG perspective that Dave could consider including here.
> 
> 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
>> 
>> 
>> 
>>

---

From: "David R. Oran" <[email-masked]>
Date: Tue, 11 Feb 2020 08:15:38 -0500

On 11 Feb 2020, at 6:22, Hitoshi Asaeda wrote:

> I have no concern about moving this forward,
Thanks!

> yet suggest to consider one thing.
>
> For the effective use of in-network cache, network coding is also 
> helpful to improve the data transmission quality. I therefore 
> recommend to add some statement explaining the way of its use or 
> adoption with some references already discussing the advantages (or 
> even difficulties) for ICN.
>
It is quite likely that network coding combined with caching can improve 
overall performance, and the current internet draft on the subject 
(https://datatracker.ietf.org/doc/draft-irtf-nwcrg-nwc-ccn-reqs/) does a 
good job of justifying this.

Where I’d like some help is in articulating how NC might interact with 
Quality of Service as I’ve defined it in this QoSArch document. Given 
that my definition centers on penalizing some users in order to give 
better performance to others, it’s not clear to me what effect the use 
or non-use of network coding has on that, or more granularly which NC 
parameters might get applied to one user’s data compared to 
another’s in order to achieve that bias.

One somewhat related concern for this document is that it starts from 
the point of view of QoS being a way to adjust link and cache resource 
allocation to favor some data over other data. It might be problematic 
to introduce discussions of network coding and its interaction with 
congestion control here since that whole general area is still in flux 
and the subject of some uncertainties (c.f. 
https://datatracker.ietf.org/doc/draft-irtf-nwcrg-coding-and-congestion/).

Thanks,
DaveO.

>>> 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?
>>
>> 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.
>>>>
>>>>

DaveO

---

From: Colin Perkins <[email-masked]>
Date: Tue, 11 Feb 2020 22:30:55 +0000

Sounds good – thanks!
Colin

> On 11 Feb 2020, at 11:00, Dirk Kutscher <[email-masked]> wrote:
> 
> Thanks, Colin.
> 

-- 
Colin Perkins
https://csperkins.org/