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

From: Damien Saucez <[email-masked]>
Date: Sun, 9 Nov 2014 16:18:42 -1000

Hello,

On 21 Oct 2014, at 22:42, Ioannis Psaras <[email-masked]> wrote:

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

This example is correct indeed, but lets take another one where you have two
flies f1 and f2.  f1 is 2000Mb (expressed in bits just for the simplicity of
the discussion) long and f2 is 2Mb long.  Download of f1 and f2 start at the
same time.  Assuming an RTT-based AIMD feedback loop, if there is no cache, the
two downloads will start with the same speed that is equal to the capacity
divided by 2 (i.e., 1 Mbps). As f2 is much shorter than f1 it will be completed
before f1 and its completion time is 2s.

Now imagine that f1 is cached completely at B.  Downloads of f1 and f2 are
still competing.  If we keep your example, during the competition, f1 is
downloaded at 1.5Mbps, meaning that f2 is downloaded at 0.5Mbps.  At that
speeds, completion time would be ~13333s for f1 and 4s for f2.  As we can see
f1 cannot be completed before f2 so it means that f2 is negatively impacted by
the cached content throughout its download time.

If you prefer to consider same size files you can take the case of three files,
two downloaded back to back and one downloaded in parallel.

This example is not to say that caching is negative but instead to show that
all parts of the system must be thought carefully before saying that the solution
will always be beneficial.

Regards,

Damien Saucez 

> =======================
> 
> Cheers,
> Yiannis.
> 
> On 21 Oct 2014, at 23:13, Manolis Sifalakis wrote:
> 
>> 
>> 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.
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> icnrg mailing list
>> [email-masked]
>> https://www.irtf.org/mailman/listinfo/icnrg
> 
> _______________________________________________
> icnrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg

---

From: Manolis Sifalakis <[email-masked]>
Date: Wed, 12 Nov 2014 00:17:57 +0100

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

Will have to read that, sounds interesting!

>> To my understanding though, he buffering/queuing
>> issue is not affected by whether content is retrieved from a cache
>> or not.
>>

Ioannis,

cached or not maybe does not matter, it is the BDP to where the chunks 
are located that does matter a lot for how queues are occupied by an 
ala-TCP strategy. The depth of the queues does change the BDP. 
Admissibility to the queues is affected by the flow's reaction to the 
measured BDP. And "flows" with different path delays (because of the 
BDP) receive different quality feedback in an ala-TCP strategy.

All these create a circular condition that is not captured in your and 
Demian's "toy examples", but there should be a strong interaction with 
the queuing. At the most extreme case a very deep en path queue could be 
"a cache".

> This example is not to say that caching is negative but instead to
> show that all parts of the system must be thought carefully before
> saying that the solution will always be beneficial.

Damien,

Well beneficial or not it seems to be a chicken and egg situation, no ? 
.. When caching was assumed beneficial, Van did not state that an 
ala-TCP strategy is to be used in ICN. Now, you come assuming an ala-TCP 
strategy and claim caching will not be beneficial. The two may be 
incompatible/adverse but that is different from the generalisation you 
make, no?

A last remark, are you sure it is AIMD (aka the controlled response) 
that correlates with the problem and not the feedback signal, namely the 
sRTT variance?

I call it ala-TCP strategy because I m almost convinced it is not the 
AIMD response in itself the problem. In one of the papers in the list I 
sent last time, the authors showed much better capacity use under AIMD 
reaction but when the feedback is based on the inter-arrivals and not 
the RTT!

best

M.

---

From: Damien Saucez <[email-masked]>
Date: Tue, 11 Nov 2014 13:43:26 -1000

On 11 Nov 2014, at 13:17, Manolis Sifalakis <[email-masked]> wrote:

> cached or not maybe does not matter, it is the BDP to where the chunks are located that does matter a lot for how queues are occupied by an ala-TCP strategy. The depth of the queues does change the BDP. Admissibility to the queues is affected by the flow's reaction to the measured BDP. And "flows" with different path delays (because of the BDP) receive different quality feedback in an ala-TCP strategy.
> 
> All these create a circular condition that is not captured in your and Demian's "toy examples", but there should be a strong interaction with the queuing. At the most extreme case a very deep en path queue could be "a cache".
> 
> 
> Well beneficial or not it seems to be a chicken and egg situation, no ? .. When caching was assumed beneficial, Van did not state that an ala-TCP strategy is to be used in ICN. Now, you come assuming an ala-TCP strategy and claim caching will not be beneficial. The two may be incompatible/adverse but that is different from the generalisation you make, no?
> 

I never said that a "à la TCP" strategy was mandatory. I just said that in some situations,
such as when a naive “à la TCP” congestion control mechanism is used, caching may
have negative impact. This is just to say that all layers must be carefully designed when
ICN is designed because each one is influencing the others.

> A last remark, are you sure it is AIMD (aka the controlled response) that correlates with the problem and not the feedback signal, namely the sRTT variance?

That depends on what you are looking at. In what you call our "toy examples”, the problem
is not the variance, just the RTT feedback based congestion control. So no, it is not AIMD,
it is the fact that the throughput is linked to the RTT, any solution using the RTT as a
feedback loop is likely to present the same fairness problem, that may ultimately results in
performance reduction compared to not using the cache.

> 
> I call it ala-TCP strategy because I m almost convinced it is not the AIMD response in itself the problem. In one of the papers in the list I sent last time, the authors showed much better capacity use under AIMD reaction but when the feedback is based on the inter-arrivals and not the RTT!

You are perfectly right so I invite you to read the paper as all this is explained there…

Damien Saucez

---

From: Manolis Sifalakis <[email-masked]>
Date: Wed, 12 Nov 2014 21:11:29 +0100

> You are perfectly right so I invite you to read the paper as all this is explained there…
  ok .. will do. its been placed at the top of the ToRead stack. ;)

M.