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

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

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

> Hi,
>
> Sorry for the late response.
> 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.

> Regards,
>
> Hitoshi
>
>
>
>> On Feb 11, 2020, at 20:00, Dirk Kutscher <[e-mail]> wrote:
>>
>> 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
>>>> [e-mail]
>>>> https://www.irtf.org/mailman/listinfo/icnrg
>>>
>>>
>>>
>>> -- 
>>> Colin Perkins
>>> https://csperkins.org/
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> icnrg mailing list
>>> [e-mail]
>>> https://www.irtf.org/mailman/listinfo/icnrg
>>
>> _______________________________________________
>> icnrg mailing list
>> [e-mail]
>> https://www.irtf.org/mailman/listinfo/icnrg
>
> _______________________________________________
> icnrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/icnrg

DaveO