Less Pain, Most of the Gain: Incrementally Deployable ICN - PowerPoint PPT Presentation

Less ¡Pain, ¡Most ¡of ¡the ¡Gain: ¡ Incrementally ¡Deployable ¡ICN ¡ Seyed ¡K. ¡Fayazbakhsh, ¡Yin ¡Lin, ¡Amin ¡Tootoonchian, ¡ ¡ Ali ¡Ghodsi, ¡Teemu ¡Koponen, ¡Bruce ¡Maggs, ¡ ¡ KC ¡Ng, ¡Vyas ¡Sekar, ¡ScoE ¡Shenker ¡ 1 ¡

A ¡high-­‑level ¡view ¡of ¡ICN ¡ S1 ¡ ¡ e.g., ¡CCN, ¡DONA, ¡NDN, ¡4WARD ¡…. ¡ ¡ ¡ C ¡ C ¡ S2 ¡ ¡ ¡ C ¡ • Decouple ¡“what” ¡from ¡“where” ¡ • Bind ¡content ¡names ¡to ¡intent ¡ Today: ¡Fetch ¡from ¡server ¡IP ¡ • Equip ¡network ¡with ¡content ¡caches ¡ • Route ¡based ¡on ¡content ¡names ¡ ¡e.g., ¡find ¡nearest ¡replica ¡ 2 ¡

Gains ¡of ¡deploying ¡ICN ¡ ¡ ¡ e.g., ¡CCN, ¡DONA, ¡NDN, ¡4WARD ¡…. ¡ ¡ C ¡ ¡ C • Lower ¡latency ¡ • Reduced ¡congesZon ¡ • Support ¡for ¡mobility ¡ • Intrinsic ¡security ¡ ¡ 3 ¡

Pains ¡of ¡deploying ¡ICN ¡ ¡ ¡ ¡ e.g., ¡CCN, ¡DONA, ¡NDN, ¡4WARD ¡…. ¡ C ¡ ¡ ¡ C ¡ • Routers ¡need ¡to ¡be ¡upgraded ¡ • RouZng ¡needs ¡to ¡be ¡content ¡based ¡ 4 ¡

MoZvaZon ¡for ¡this ¡work ¡ Lower ¡latency ¡ • Reduced ¡congesZon ¡ • Gains ¡ Support ¡for ¡mobility ¡ • Intrinsic ¡security ¡ ¡ • Can ¡we ¡get ¡ICN ¡gains ¡without ¡the ¡pains? ¡ e.g., ¡exisZng ¡technologies? ¡ ¡ e.g., ¡incrementally ¡deployable? ¡ ¡ Routers ¡need ¡to ¡be ¡upgraded ¡with ¡caches ¡ • Pains ¡ RouZng ¡needs ¡to ¡be ¡content ¡based ¡ • 5 ¡

Approach: ¡AEribute ¡gains ¡to ¡tenets ¡ QuanZtaZve ¡ QualitaZve ¡ • Lower ¡latency ¡ ¡ • Reduced ¡congesZon ¡ • Support ¡for ¡mobility ¡ ¡ • Intrinsic ¡security ¡ ¡ • Decouple ¡“what” ¡from ¡“where” ¡ • Bind ¡content ¡names ¡to ¡intent ¡ • Equip ¡network ¡with ¡content ¡caches ¡ • Route ¡based ¡on ¡content ¡names ¡ 6 ¡

Key ¡Takeaways ¡ • To ¡achieve ¡quanZtaZve ¡benefits: ¡ à Just ¡cache ¡at ¡the ¡“edge” ¡ à With ¡Zipf-­‑like ¡workloads, ¡pervasive ¡caching ¡and ¡ nearest-­‑replica ¡rouZng ¡don’t ¡ ¡add ¡much ¡ ¡ • To ¡achieve ¡qualitaZve ¡benefits: ¡ à Build ¡on ¡HTTP ¡ ¡ Basis ¡for ¡incrementally ¡deployable ¡ICN ¡ 7 ¡

Outline ¡ • Background ¡and ¡Approach ¡ • Analyzing ¡quan,ta,ve ¡benefits ¡ • QualitaZve ¡benefits ¡ à ¡Incrementally ¡deployable ¡ICN ¡ ¡ • Discussion ¡ ¡ 8 ¡

Design ¡space ¡of ¡caching ¡ ¡ • QuanZaZve ¡benefits ¡are ¡largely ¡due ¡to ¡caching ¡ ¡ ¡ • Two ¡key ¡dimensions ¡to ¡this ¡design ¡space: ¡ – Cache ¡placement ¡ ¡ • E.g., ¡everywhere? ¡Edge? ¡ – Request ¡rouZng ¡ • E.g., ¡shortest ¡path, ¡nearest ¡replica? ¡ 9 ¡

RepresentaZve ¡points ¡in ¡design ¡space ¡ ¡ ¡ ¡ ¡ ¡Cache ¡Placement ¡ ¡ ¡ ¡ ¡Request ¡RouZng ¡ ICN-­‑SP ¡ Everywhere ¡ Shortest ¡path ¡to ¡origin ¡ ICN-­‑NR ¡ Everywhere ¡ Nearest ¡replica ¡ Edge ¡ Only ¡at ¡edge ¡nodes ¡ ¡ Shortest ¡path ¡to ¡origin ¡ ¡ Edge-­‑Coop ¡ Only ¡at ¡edge ¡nodes ¡ ¡ Shortest ¡path ¡to ¡origin ¡ ¡ Edge ¡neighbors ¡alone ¡ 10 ¡

SimulaZon ¡setup ¡ Edge ¡ Real ¡CDN ¡ request ¡ ¡logs ¡ Cache ¡provisioning ¡ ~ ¡5% ¡of ¡objects ¡ Uniform ¡or ¡ProporZonal ¡ LRU ¡replacement ¡ PoP-­‑level ¡topologies ¡(Rockecuel) ¡augmented ¡with ¡access ¡trees ¡ Assume ¡name-­‑based ¡rouZng, ¡lookup ¡incurs ¡zero ¡cost ¡ 11 ¡

Request ¡latency ¡ 100 ICN-SP EDGE Query latency improvement (%) ICN-NR EDGE-Coop 80 % ¡ ¡ 60 improvement ¡ over ¡ 40 “no-­‑cache” ¡ 20 0 ¡ ¡Telstra ¡ ¡ ¡ ¡ ¡ ¡ ¡Sprint ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡Level3 ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡AT&T ¡ Gap ¡between ¡architectures ¡is ¡small ¡(< ¡10%) ¡ ¡ Similar ¡results ¡for ¡congesZon ¡+ ¡server ¡load ¡ 12 ¡

SensiZvity ¡Analysis ¡ 25 Latency Congestion Performance gain of ICN-NR 20 Origin-Load over EDGE (%) 15 % ¡gap ¡ ¡ ICN-­‑NR ¡ 10 ¡-­‑ ¡ ¡Edge ¡ 5 0 -5 Best ¡ ¡case ¡ Normalize ¡ Double ¡ Baseline ¡ Even ¡in ¡best ¡case, ¡ICN-­‑NR ¡is ¡only ¡17% ¡beEer ¡ Gap ¡can ¡be ¡easily ¡reduced ¡ 13 ¡

ImplicaZons ¡of ¡Edge ¡Caching ¡ • Incrementally ¡deployable ¡ – Domains ¡get ¡benefits ¡without ¡relying ¡on ¡others ¡ • IncenZve ¡deployable ¡ – Domains’ ¡users ¡get ¡benefits ¡if ¡domain ¡deploys ¡caches ¡ 14 ¡

Outline ¡ • Background ¡and ¡moZvaZon ¡ ¡ • Approach ¡ ¡ ¡ • QuanZtaZve ¡benefits ¡of ¡ICN ¡ ¡ • Qualita,ve ¡benefits ¡ à à ¡Incrementally ¡deployable ¡ICN ¡ • Discussion ¡ ¡ 15 ¡

RevisiZng ¡QualitaZve ¡Aspects ¡ 1. Decouple ¡names ¡from ¡locaZons ¡ ¡ ¡Build ¡on ¡HTTP ¡ ¡ – Can ¡be ¡viewed ¡as ¡providing ¡“get-­‑by-­‑name” ¡abstracZon ¡ – Can ¡reuse ¡exisZng ¡web ¡protocols ¡(e.g., ¡proxy ¡discovery) ¡ 2. ¡Binding ¡names ¡to ¡intents ¡ Use ¡self-­‑cerZfying ¡names ¡ ¡ e.g., ¡“Magnet” ¡URI ¡schemes ¡ Extend ¡HTTP ¡for ¡“crypto” ¡and ¡other ¡metadata ¡ 16 ¡

idICN: ¡Content ¡RegistraZon ¡ Name ¡ResoluZon ¡System ¡ Register ¡ L.P.idicn.org ¡ Reverse ¡ P ¡= ¡Hash ¡of ¡ ¡public ¡key ¡ ¡ Proxy ¡ L ¡= ¡content ¡label ¡ Publish ¡ content ¡ e.g., ¡hEp://en.5671….fda627b.idicn.org/wiki/ ¡ Origin ¡Server ¡ 17 ¡

idICN: ¡Client ¡ConfiguraZon ¡ Name ¡ResoluZon ¡System ¡ Proxy ¡ Edge ¡ ¡ Reverse ¡ Cache ¡ Proxy ¡ AutomaZc ¡Proxy ¡Discovery ¡ e.g., ¡WPAD ¡ Client ¡ Origin ¡Server ¡ 18 ¡

idICN: ¡Content ¡Delivery ¡ Name ¡ResoluZon ¡System ¡ Try ¡it ¡out: ¡ ¡ www.idicn.org ¡ 2. ¡Name ¡ resoluZon ¡ 3. ¡Rqst ¡by ¡address ¡ Reverse ¡ Proxy ¡ Proxy ¡ Edge ¡ 5. ¡ ¡Response ¡ ¡+ ¡Metadata ¡ ¡ Cache ¡ 1. ¡Rqst ¡ 4. ¡Fetch ¡ 6. ¡Response ¡ L.P.idicn.org ¡ ¡ ¡ Client ¡ Origin ¡Server ¡ 19 ¡

Conclusions ¡ • MoZvaZon: ¡Gains ¡of ¡ICN ¡with ¡less ¡pain ¡ – Latency, ¡congesZon, ¡security ¡ ¡ – Without ¡changes ¡to ¡routers ¡or ¡rouZng! ¡ • End-­‑to-­‑end ¡argument ¡applied ¡to ¡ICN ¡design ¡space ¡ ¡ ¡ • Can ¡get ¡most ¡quanZtaZve ¡benefits ¡with ¡“edge” ¡soluZons ¡ – Pervasive ¡caching, ¡nearest-­‑replica ¡rouZng ¡not ¡needed ¡ • Can ¡get ¡qualitaZve ¡benefits ¡with ¡exisZng ¡techniques ¡ – With ¡exisZng ¡HTTP ¡+ ¡HTTP-­‑based ¡extensions ¡ – Incrementally ¡deployable ¡+ ¡backwards ¡compaZble ¡ • idICN ¡design: ¡one ¡possible ¡feasible ¡realizaZon ¡ – Open ¡issues: ¡economics, ¡other ¡benefits, ¡future ¡workloads ¡.. ¡ ¡ 20 ¡