Subject: Re: [icnrg] Reflection on the QoE with ICN

From: Manolis Sifalakis <[email-masked]>
Date: Tue, 21 Oct 2014 22:13:05 +0000

Reading this discussion so far seems like a dog chasing its tail.

First of all the proposed addition to the draft is not adding or 
removing any value. It does not stimulate thinking or provide any insight.

Sorry for the critique but the discussion thread seems to be chaotic, 
and too abstract to provoke any constructive thinking...

I would prefer to see more "meaty" statements in the draft

- Please define QoS, how do you propose it is measured, where is it to 
be leveraged in ICNs ?

- Similarly for QoE.

Moreover differentiate which are the dependencies of each. And please 
help identify the connections to network dynamics and discuss 
requirements/challenges for

  1. Transport mechanisms or strategies that control ICN dynamics
  2. Caching strategies

It seems that the mindset of many ppl is still trapped in TCP/IP, where 
the dynamics are only controlled by TCP, and where queue 
management/traffic shaping/traffic conditioning (QoS related mechanisms) 
aim to influence TCP.

Do we have a reason for such assumptions ??

FYI there is a heck of literature in the last 3-4 years exploring AIMD 
window based mechanisms for flow control in ICN (see list at the end of 
the email) with a lot of insights in relevance to QoS. They all converge 
to a couple of simple facts worth of summing up and mentioning in a draft..

1. Caching increases the variability of an RTT estimator (for the 
purpose of assesing a pipe for windowed transmission), the distribution 
of which might not even be bell-shaped

2. Assuming and trying to approximate a single BDP/pipe for flow-control 
is sub-optimal when in fact there might be multiple BDPs (to each point 
in the net from where data are coming)

3. AIMD controlled by an RTT estimator is thus disfunctional and 
problematic for ICN w/ caching enabled

4. AIMD ala TCP requires ordered arrival of packets. In ICN this is a 
limitation(!) since oo-order requests/arrivals are not only possible, 
but probably desired (exploit parallisation).

5. An AIMD window of transmissions controlled by jitter variability 
seems to have much smoother characteristics than one controlled by RTTs

6. In-network measures seem to be a MUST, they fit better the hop-by-hop 
communication. Whatever AQM, interest caressing/shaping etc will end up 
in place will be directly related to QoS. Now AQM is stand-alone, while 
QoS requires cooperation. What are the implications of this ?

7. .. others I might be missing ..

The main lessons so far have been ...

A. Should a transport strategy be copying what TCP does ? Most probably 
NOT! -- this implies that QoS mechanisms need to be more broad visioned

B. Caching may play a major role in dynamics and transport issues 
(depending on what is the feedback signal based on). Edge vs in-net 
caching, en-path vs oo-path caching, single-path vs multi-path caching, 
as well as replacement strategies (per chunk vs per content vs per 
block-of-chunks, lru/lfu/etc) ... are all open issues worth of attention 
and exploration (rather than re-overfocusing on RTT-driven AIMDs) and 
worth of a connection to QoS.

And finally there is the million dollar/euro question. Will ICN be 
deployed over TCP/IP?, together with TCP/IP?, or after TCP/IP is 
switched-off :P ? Unless you are voting for the last, there is a 
cross-interaction between QoS measures in TCP/IP and ICN !!! Should we 
not be thinking about compatibility, use of QoS for separation, 
implications ?

best

m.

PS: In advance disclaimer -- this post is intended to raise awareness, 
not to volunteer editorial effort for the draft ;).

--- list of refs (aside of the one mentioned in the thread as I ve not 
read it) ---

M. Amadeo, A. Molinaro, C. Campolo, M. Sifalakis and C. Tschudin, 
"Transport Layer Design for Named Data Wireless Networking". In Proc. of 
the 33rd IEEE INFOCOM, Workshop on Named Oriented Mobility, 2014.

M. Sifalakis, S. Braun, M. Monti and C. Tschudin, "An Empirical Study of 
Receiver-based AIMD Flow-Control Strategies for CCN", in Proc. of the 
22nd ICCCN, 2013.

L. Saino, C. Cocora, and G. Pavlou, “CCTCP: A scalable receiver-driven 
congestion control protocol for content centric networking,” in Proc. of 
IEEE ICC, 2013

M. Amadeo, A. Molinaro, and G. Ruggeri, “E-CHANET: Routing, Forwarding 
and Transport in Information-Centric Multihop Wireless Networks,” 
Computer Communications, 36 (7), 2013

S. Braun, M. Monti, M. Sifalakis and C. Tschudin, "CCN & TCP 
co-existence in the Future Internet: Should CCN be compatible to TCP?", 
in Proc. of IEEE/IFIP IM Symposium, Workshop on Management of the Future 
Internet, 2013

M. Amadeo, C. Campolo, and A. Molinaro, “Design and analysis of a 
transport-level solution for content-centric VANETs,” in Proc. IEEE ICC 
Workshop on Emerging Vehicular Networks: V2V/V2I and Railroad 
Communications, 2013

G. Carofiglio, M. Gallo, and L. Muscariello, “Joint hop-by-hop and 
receiver-driven interest control protocol for content-centric networks,” 
in Proc. 2nd ACM Workshop ICN ’12, 2012.

G. Carofiglio, M. Gallo, and L. Muscariello, “Multipath congestion 
control in content-centric networks,” in Proc. IEEE INFOCOM Int’l 
Conference, 2013.

Y. Wang, N. Rozhnova, A. Narayanan, D. Oran, and I. Rhee, “An improved 
hop-by-hop interest shaper for congestion control in named data 
networking,” in ACM SIGCOMM ICN Workshop, 2013

S. Oueslati, J. Roberts, and N. Sbihi, “Flow-aware Traffic Control for a 
Content-Centric Network,” in Proc. IEEE INFOCOM Int’l Conference, 2012.

N. Rozhnova and S. Fdida, “An effective hop-by-hop interest shaping 
mechanism for ccn communications,” in Proc. 1st IEEE Workshop on 
Emerging Design Choices in Name-Oriented Networking, 2012

G. Carofiglio, M. Gallo, and L. Muscariello, “ICP: Design and evaluation 
of an interest control protocol for content-centric networking,” in 
Proc. 1st IEEE Int’l Workshop on Emerging Design Choices in 
Name-Oriented Networking, 2012.

---

From: Damien Saucez <[email-masked]>
Date: Wed, 22 Oct 2014 02:02:10 +0200

Dear Manolis,

comments inline.

> I would prefer to see more "meaty" statements in the draft

This is why it starts on the mailing list, so we can make clear statements in
the drafts based on the feedback we get from people.

> - Please define QoS, how do you propose it is measured, where is it to 

see section 2.4.1 of draft-irtf-icnrg-evaluation-methodology for a first
proposition of definition and measurements.

>  1. Transport mechanisms or strategies that control ICN dynamics

Articulating the QoS/QoE discussing around these two points would indeed
make the discussion clearer. Thank you for the suggestion.

> not be thinking about compatibility, use of QoS for separation, 

That would certainly be an interesting discussion to have while talking about
transport and congestion techniques but this level of detail is not relevant
for our subject.  The purpose here is just to inform (remind?) people that
because of the very nature of ICN (NDOs come from anywhere, potentially
increasing variability), models used today to link QoE with QoS may not be
relevant in ICN because they mostly leverage the notion of flow and single
path, which do not make sense in ICN.

Thank you,

Damien Saucez 

> _______________________________________________
> icnrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg

---

From: Ioannis Psaras <[email-masked]>
Date: Wed, 22 Oct 2014 09:42:16 +0100

Hi all,

IMO there have been two different discussions going on for a while in this thread:

1. the macro-level cache effect on delivery performance,
2. the micro-level buffer/queue effect on delivery performance,
(let's group QoS and QoE in the term delivery performance, as for the purpose of this discussion I think it does not make a difference, e.g., we're not taking about a delay-sensitive voice/video application/session).

At the macro-level (and although, Damien, I have not yet read the Networking'14 paper referenced earlier), I agree with Cedric that getting some chunk(s) from a near-by cache can only but improve performance (see example at end of message). This, however, as also pointed out below by Manolis will cause TCP mechanisms to fail miserably, due to wrong estimations of the RTT and therefore timers. Our colleagues at UCL ([5] in Manolis's email below) have tried to deal with this (maybe others have also worked on that - please provide pointers). The reason for this is that the mechanisms of TCP cannot cope with multi-sender sessions. This certainly requires further attention.

At the micro-level, queues will grow according to the sending rates of flows (whatever the definition of a flow is in an ICN environment) and therefore depends on the sending pattern (e.g., AIMD or equivalent). On this, as Manolis points out below, it depends whether we assume an AIMD-like congestion control mechanism or not. We are questioning the efficiency of an AIMD mechanism for ICN environments in our recent paper (http://www.ee.ucl.ac.uk/comit-project/files/inrp-hotnets14.pdf) to be presented at HotNets next week. Any opinion or criticism on this very welcome! To my understanding though, he buffering/queuing issue is not affected by whether content is retrieved from a cache or not.

Example on effect of caches (again, I have not read Damien's paper):
======================

Assume topology A-B-C, where A: client, B: router/cache, C: sender, bandwidth(A-B)=bandwidth(B-C)=2Mbps, delay(A-B)=delay(B-C). We intend to transmit a 6 Mbit file to A, but half of it, chunk 1 say (i.e., 3Mbits) is cached at B and the rest, chunk 2 is stored at C. Assuming AIMD and due to the RTT unfairness issues, the subflow transmitting chunk 1 will occupy (roughly) 3/4 of the A-B 2Mbps link (that is, 1,5Mbps) and will complete in 2 secs. In those same 2 secs, chunk 2 (being transferred between C-A) will have transmitted 1Mbit in total at 0,5Mpbs (the remaining capacity between B and A).

At this point the chunk 1 subflow will complete and will leave the 2Mbps e2e link C-A to chunk 2, which will transfer the remaining 2Mbits in 1 sec (over the 2Mbps e2e link). Total time is 3 secs for the transfer, the same as it would be without a cache. However, the link C-B will remain less utilised throughout the duration of the transfer, which can be considered good for a variety or reasons. Also, if chunk 1 is the first part of the file/stream this will also improve delivery performance as seen by the user.
=======================

Cheers,
Yiannis.