| 1 | | == ICN 2016 Reviews == |
| 2 | | |
| 3 | | === A Practical Congestion Control Scheme for Named Data Networking === |
| 4 | | '''Overall merit''': Weak accept (top 30% but not top 10%)\\ |
| 5 | | '''Confidence''': Expert\\ |
| 6 | | '''Quality of writing''': Well written\\ |
| 7 | | '''Summary of the paper''': \\ |
| 8 | | This paper proposed PCON, a congestion control mechanism in NDN that takes advantage of active queue management (!CoDel) and considers multipath and overlay link scenarios. |
| 9 | | The paper is well written, and the use of !CoDel with marking and the local loss detection are novel. |
| 10 | | However, the problems with the paper include: the multipath component does not seem to work with receiver window control, the name-based multipath and overlay link solution does not seem to be efficient, nor is the evaluation strong enough. |
| 11 | | Please see the comments below for details. |
| 12 | | |
| 13 | | '''Strengths''': (Be brief)\\ |
| 14 | | * The solution uses receiver-driven congestion control with AQM, which can avoid multiple efficiency issues and buffer-bloat. However, using AQM is not novel ![1]. |
| 15 | | * The solution uses !CoDel with marking, which is novel. |
| 16 | | * Introducing another layer between the network and link layer to ensure hop-by-hop loss detection (rather than reliability) is novel. |
| 17 | | * The paper is well written. |
| 18 | | |
| 19 | | '''Weaknesses''': (Be brief)\\ |
| 20 | | * The multipath solution does not work properly with the window adjustment on the consumer size. |
| 21 | | * The per FIB entry based multipath and highly congested link solution does not seem to be feasible or efficient. |
| 22 | | * The evaluation is not adequate. |
| 23 | | |
| 24 | | '''Detailed comments''':\\ |
| 25 | | This paper proposed a congestion control mechanism in NDN. |
| 26 | | The basic solution comprises a consumer-driven window adjustment with AQM which decouples the congestion notification from packet loss (although the authors claim it is hop-by-hop solution). |
| 27 | | This solution can effectively address the efficiency and scalability issues caused by pure hop-by-hop flow-based fair queueing, buffer bloat, and etc. |
| 28 | | To enhance the solution, the authors proposed FIB-based multipath solution which would dynamically pick "forward percentage" ''for each FIB entry'' among all the outgoing faces. |
| 29 | | To detect loss (which is now decoupled from congestion), the paper proposed a light-weight loss detection mechanism between layer 2 and layer 3. |
| 30 | | For the highly congested links caused by lower-layer multiplexing and/or unresponsive consumers, the solution simply disables a face to such a link and try to choose other paths. |
| 31 | | |
| 32 | | While the paper is overall well written, there exists some critical issues with design and evaluation: |
| 33 | | * The multipath solution is based on each FIB prefix. This might cause a set of problems. E.g., if we have a flow with prefix "/flow" which has 1 entry in FIB. A packet "/flow/seg_255" has another entry (maybe it is cached somewhere else). The forward percentage on "/flow" will not be affected on "/flow/*" and the forwarding might not follow the forwarding percentage.\\ |
| 34 | | Another example is, if you have flows with prefixes "/flow1" and "/flow2", and they share a same set of outgoing faces on a router. However, the forwarding percentage are not shared among flows. How can it ensure fairness (across flows?) |
| 35 | | * Another problem with MP solution is the dynamics between the consumer window adjustment and multipath forwarding percentages. When none of the multiple paths is saturated, the solution would shift the traffic back to the path with lowest latency. This is what might happen: 1) the consumer increases the window and saturate the paths and the paths share the traffic; 2) the consumer receives marks and reduce the window size (and reduce the receive rate, so that the traffic is shifted back to the low-delay link; 3) the consumer would repeat 1 and cause oscillation.\\ |
| 36 | | Also, at the beginning, the solution only uses low-latency link until it is saturated. It is not efficient. The consumer would reduce the rate on seeing marks here, which would worsen the problem. |
| 37 | | * Fairness -- one of the most critical aspects with congestion control mechanism -- is only evaluated on a simple topology in 4.4, and it is left to the future work! |
| 38 | | * In the introduction (paragraph 3) and abstract, the authors mixed varying data chunk sizes and data packet sizes. While it is true that the data chunk size would change according to the applications, the data packet size can be kept same via the use of some transport protocols at the provider side. In the evaluation (4.3 - payload), the result shows that the solution cannot deal with varying packet size well, which includes overkill and high latency (maybe also unfairness??) when the packet size increases, and under-utilize the network when the packet size decreases. It is not suggested to assume varying data ''packet'' size for a transport protocol. |
| 39 | | * The performance of using of !CoDel with ECN is not clear. !CoDel is designed to work with packet drop. This paper proposed a marking solution to improve the efficiency. However, the performance of !CoDel with marking is not well studied (or referenced to a more detailed study). |
| 40 | | * In section 2.1, "second" point, the authors claim that they mitigate this problem by making buffers large enough. How large can be seen as enough? |
| 41 | | * For highly-congested links, the authors would simply disable the path. Is it possible that an attacker can easily perform DoS attack with this mechanism? |
| 42 | | * The evaluations are only carried on simple topologies (with only 1 bottleneck). Which is definitely not adequate for a congestion control paper. Here are some more detailed comments: |
| 43 | | * In sec. 4.2, you should show queue size and window size. |
| 44 | | * In sec. 4.3, you used 100B payload size as default value. Why is it that small? Are you using the same value with other evaluations? |
| 45 | | * In sec. 4.3 payload, you can see that the solution caused huge delay (to 3 seconds!). What about the fairness? That's the problem with !CoDel but not dropping packets. In the throughput, it is quite obvious that you are overkilling the traffic at around 12th second. Which means your window control does not work well with the long delays. between 7th and 12th second, the delay does not change. Why is that happening? Between 5th and 10th second, the queue size is not changing, why is that happening? The paper should describe these facts more properly. |
| 46 | | * In sec. 4.3 Cross_opp_2, it is quite obvious that the solution under-utilize the network. It should be addressed more properly. |
| 47 | | * Looks like topo 4.4 is carefully picked to ensure that there is only 1 bottleneck in the network (on the provider side, p1+p2+p3=20+10+10<50 (R1-R2)). The paper should pick more complicated network for fairness and multipath evaluations. (Topo 10 has the same issue) |
| 48 | | * In Fig. 11, PCON Cwnd, looks like the window size changed dramatically and the queue size are not stable. Why is this happening? Is it an indication of a bad solution? |
| 49 | | * In table 1, here is the rate/avg (for fairness). It seams that the solution is less fair even compared with ICP. |
| 50 | | || ||=ICP=||=PCON=|| |
| 51 | | ||=C1=||0.621531632||0.504285975|| |
| 52 | | ||=C2=||0.715871254||0.617362758|| |
| 53 | | ||=C3=||0.879578246||0.84989969|| |
| 54 | | ||=C4=||1.09045505||1.157213204|| |
| 55 | | ||=C5=||1.692563818||1.871238373|| |
| 56 | | |
| 57 | | |
| 58 | | |
| 59 | | |
| 60 | | ![1] Zhang, Feixiong, et al. "A transport protocol for content-centric networking with explicit congestion control." 23rd International Conference on Computer Communication and Networks (ICCCN). IEEE, 2014. |
| 61 | | |
| 62 | | === Content-Centric Networking at Internet Scale through The Integration of Name Resolution and Routing === |
| 63 | | '''Overall merit''': [Accept (top 10%) | Weak accept (top 30% but not top 10%) | Weak reject (top 50% but not top 30%) | Reject (bottom 50%) ]\\ |
| 64 | | '''Confidence''': [Expert | Knowledgeable | Some Familiarity | None]\\ |
| 65 | | '''Quality of writing''': [Excellent | Well written | Not well written | Poorly Written]\\ |
| 66 | | '''Summary of the paper''': (Provide a 1-2 sentence summary of the work in your own words, including the contribution and technical depth)\\ |
| 67 | | |
| 68 | | '''Strengths''': (Be brief)\\ |
| 69 | | |
| 70 | | '''Weaknesses''': (Be brief)\\ |
| 71 | | |
| 72 | | '''Detailed comments''':\\ |
| 73 | | |
| 74 | | |
| 75 | | === Sharing mHealth Data via Named Data Networking === |
| 76 | | '''Overall merit''': Weak reject (top 50% but not top 30%)\\ |
| 77 | | '''Confidence''': Expert\\ |
| 78 | | '''Quality of writing''': Well written\\ |
| 79 | | '''Summary of the paper''': (Provide a 1-2 sentence summary of the work in your own words, including the contribution and technical depth)\\ |
| 80 | | |
| 81 | | '''Strengths''': (Be brief)\\ |
| 82 | | |
| 83 | | '''Weaknesses''': (Be brief)\\ |
| 84 | | |
| 85 | | '''Detailed comments''':\\ |
| 86 | | |
| 87 | | === MIRCC: Multipath-aware ICN Rate-based Congestion Control === |
| 88 | | '''Overall merit''': [Accept (top 10%) | Weak accept (top 30% but not top 10%) | Weak reject (top 50% but not top 30%) | Reject (bottom 50%) ]\\ |
| 89 | | '''Confidence''': [Expert | Knowledgeable | Some Familiarity | None]\\ |
| 90 | | '''Quality of writing''': [Excellent | Well written | Not well written | Poorly Written]\\ |
| 91 | | '''Summary of the paper''': (Provide a 1-2 sentence summary of the work in your own words, including the contribution and technical depth)\\ |
| 92 | | |
| 93 | | '''Strengths''': (Be brief)\\ |
| 94 | | |
| 95 | | '''Weaknesses''': (Be brief)\\ |
| 96 | | |
| 97 | | '''Detailed comments''':\\ |
| 98 | | |
| 99 | | === A Consumer-Driven Access Control Approach to Censorship Circumvention in Content-Centric Networking === |
| 100 | | '''Overall merit''': [Accept (top 10%) | Weak accept (top 30% but not top 10%) | Weak reject (top 50% but not top 30%) | Reject (bottom 50%) ]\\ |
| 101 | | '''Confidence''': [Expert | Knowledgeable | Some Familiarity | None]\\ |
| 102 | | '''Quality of writing''': [Excellent | Well written | Not well written | Poorly Written]\\ |
| 103 | | '''Summary of the paper''': (Provide a 1-2 sentence summary of the work in your own words, including the contribution and technical depth)\\ |
| 104 | | |
| 105 | | '''Strengths''': (Be brief)\\ |
| 106 | | |
| 107 | | '''Weaknesses''': (Be brief)\\ |
| 108 | | |
| 109 | | '''Detailed comments''':\\ |
| 110 | | |
| 111 | | === Network Names in Content-Centric Networking === |
| 112 | | '''Overall merit''': Reject (bottom 50%)\\ |
| 113 | | '''Confidence''': Expert\\ |
| 114 | | '''Quality of writing''': Well written\\ |
| 115 | | '''Summary of the paper''': (Provide a 1-2 sentence summary of the work in your own words, including the contribution and technical depth)\\ |
| 116 | | |
| 117 | | '''Strengths''': (Be brief)\\ |
| 118 | | |
| 119 | | '''Weaknesses''': (Be brief)\\ |
| 120 | | |
| 121 | | '''Detailed comments''':\\ |
| 122 | | |
| 123 | | |
| 124 | | |
