[[TOC( Internal/PaperReadingGroup/*, depth=3, heading=Reading Sessions)]]

== 2016.09.06 - Reading session 1: ICN'16 ==

* '''Participants:''' [[StudentPages/Haoyuan|Haoyuan Xu]], [[StudentPages/Jiachen|Jiachen Chen]], [[StudentPages/sugang|Sugang Li]], [[StudentPages/Wuyang|Wuyang Zhang]], [[StudentPages/Ying|Ying Liu]], [[StudentPages/Zhenhua|Zhenhua Jia]]\\
* '''Summary:''' We managed to finish 2 papers in this meeting. We also went through some basic discussions on NDN & congestion control.

=== Papers ===
||=ID=||=Paper=||=Presenter=||=Slides=||
||=1=|| [[icn16-final105.pdf|Sharing mHealth Data via Named Data Networking]]  || [[StudentPages/sugang|Sugang]] || ||
||=2=||  [[icn16-final91.pdf|Network Names in Content-Centric Networking]] || [[StudentPages/Wuyang|Wuyang]] || ||
\\

=== Reviews ===
||=ID=||=[[StudentPages/Jiachen|Jiachen]]=||=[[StudentPages/Haoyuan|Haoyuan]]=||=[[StudentPages/sugang|Sugang]]=||=[[StudentPages/Zhenhua|Zhenhua]]=||=[[StudentPages/Ying|Ying]]=||
||=1=||[[wiki:Internal/StudentPages/Jiachen/ICN16Reviews#SharingmHealthDataviaNamedDataNetworking|Review]]|| || || || ||
||=2=||[[wiki:Internal/StudentPages/Jiachen/ICN16Reviews#NetworkNamesinContent-CentricNetworking|Review]]|| || || || ||
\\



=== Discussion Notes ===
* Named-Data Networking, Content-Centric Networking
  1. Components in a forwarding engine (FIB, PIT, Content Store)
  2. Forwarding rule
* Basic knowledge about congestion control
  1. Why window-based, how does it look like
  2. Why hop-by-hop fairness does not work (dumbell topology with 2 bottlenecks)
  3. Controlling window is not equal to controlling rate
  4. Buffer bloat and active queue management (RED/CoDel)
  5. Fast recovery and why it is not feasible in NDN
* Network Names in Content-Centric Networking
  1. This paper is not well written. Problems:
    * It did not cover the security issue mentioned in the abstract.
    * The evaluation did not compare the proposed solutions with other solutions.
    * The packet header is still with variable length in the design.
  2. However, there are also something interesting in the paper:
    * This solution enables hash, at the same time allows for longest prefix matching.
    * From the hardware design point of view, it is simpler than trie (tree), and it has comparable lookup efficiency.

* Sharing mHealth Data via Named Data Networking
  1. Problems with the paper:
    * ICN is not quite beneficial according to the solution
    * The paper assumes DSU and DPU are benign.
    * The key exchange model in sec. 2.5 is not clear. Should read the NAC citation [11] in the paper for further information. However, this should not be counted as novelty of the paper.
  2. Interesting topics in the paper:
    * The solution can benefit IP-based solutions -- we can also sign the contents in IP, rather than only securing the channels.
  3. Key exchange procedure in the paper
    1. Data generator (Fitbit) generates a data and uses a symmetric key (C-KEY) to encrypt the content.
    2. Data generator gets a key-encrypt key (KEK) from the data owner (me) and encrypts the C-KEY with KEK.
    3. Data consumer (DPU/DVU) gets a key-decrypt key (KDK) from the data owner, and get an encrypted C-KEY (by KEK), and an encrypted data (by C-KEY) from the data generator.
    4. Data consumer gets C-KEY using KDK and gets data using C-KEY.
    * '''Problem''': the data owner now reveals both KEK ''and'' KDK (a key pair) to the network. How to prevent the leak of KEK/KDK?
    * One interesting thing: there should be no pre-known mapping between data generator and consumer. A data generated now might be used by some future DPUs/DVUs.

* Basic of cryptography
  * Assumption: `U_a` has a private key `a`, `U_b` has private key `b`.
  * Todo: `U_a` and `U_b` should have a symmetric key, but `U_a` should not know `b`, nor should `U_b` know `a`. Evesdropper should know neither `a` nor `b`.
  * Prerequirement: there are two well-known integers `q` and `g`.
  * Process:
    1. `U_a` sends `A = q ^ a % g` to `U_b`
    2. `U_b` sends `B = q ^ b % g` to `U_a`
    3. `U_a` uses `B ^ a % g` as the key
    4. `U_b` uses `A ^ b % g` as the key
  * Proof of symmetric:\\
    `A ^ b % g` = `(q ^ a % g) ^ b % g`\\
    Let `q ^ a` = `n * g + v_a` (`v_a` = `q ^ a % g`)\\
    We can get:\\
    `(q ^ a - n * g) ^ b % g` = `(q ^ (ab) + ? * g + ? * g ^ 2 + ... + ? * g ^ b) % g` \\
    `(q ^ a - n * g) ^ b % g` = `(q ^ (ab)) % g`\\
    Similarly, we can get `B ^ a % g` = `(q ^ (ab)) % g`\\
    Therefore, `B ^ a % g` == `A ^ b % g` (symmetric).
  * With proper `q` value, we cannot get `x` from `q ^ x % g`. Therefore `U_a` will not know `b`, nor will `U_b` know `a`, or evesdropper know `a` or `b`.