TF6 ¡ ¡ New ¡Transport ¡Protocols ¡ fidel.liberal@ehu.eus ¡ Contributors: ¡ ¡ Eneko ¡Atxutegi ¡@KAU ¡@EHU ¡ Åke ¡Arvidsson ¡@ERC ¡ Anna ¡Brunstrom, ¡KJ ¡Grinnemo ¡@KAU ¡ 1 ¡
New ¡protocols/services ¡vs ¡TCP ¡ LEDBAT ¡ • RFC6817 ¡-‑> ¡hTps://tools.ieU.org/html/rfc6817 ¡(December ¡2012) ¡ – PRR ¡ • RFC6937 ¡-‑> ¡hTps://tools.ieU.org/html/rfc6937 ¡(May ¡2013) ¡ – HTTP/2 ¡ • RFC7540 ¡-‑> ¡hTps://tools.ieU.org/html/rfc7540 ¡(May ¡2015) ¡ – QUIC ¡ • Overview ¡-‑> ¡hTps://peering.google.com/about/quicfaq.html ¡ – SPUD ¡ • IETF ¡(sfll ¡defining) ¡-‑> ¡hTps://tools.ieU.org/html/drag-‑hildebrand-‑spud-‑prototype-‑03 ¡(March ¡09, ¡2015) ¡ – CAIA ¡ • hTp://caia.swin.edu.au/urp/newtcp/tools.html ¡ – TAPS ¡ • IETF ¡WG ¡-‑> ¡hTp://datatracker.ieU.org/wg/taps/charter/ ¡-‑> ¡Last ¡milestone ¡proposed ¡for ¡Mar ¡2016 ¡ ¡ – RMCAT ¡ • IETF ¡WG ¡-‑> ¡hTps://datatracker.ieU.org/wg/rmcat/charter/ ¡-‑> ¡ ¡Last ¡milestone ¡proposed ¡for ¡Oct ¡2016 ¡ – ICCRG ¡ • IETF's ¡IRTF ¡-‑> ¡ ¡Being ¡a ¡main ¡goal ¡to ¡"produce ¡an ¡RFC ¡describing ¡the ¡nature ¡of ¡the ¡emerging ¡congesfon ¡ – control ¡problems ¡that ¡any ¡future ¡congesfon ¡control ¡architecture ¡must ¡face". ¡ 2 ¡
Use ¡case: ¡LTE ¡>=4G ¡mobile ¡scenario ¡ • Today ¡ – Performance ¡of ¡current ¡Transport ¡protocols/CCA ¡ over ¡LTE ¡ • New ¡paradigms ¡ – Caching ¡in ¡eMBMS ¡ – MEC ¡ 3 ¡
Simulated/Emulated ¡environment ¡ If ¡ we ¡ don't ¡ understand ¡ the ¡ Focus ¡on ¡LTE ¡part: ¡ interacfon ¡ between ¡ LTE ¡ and ¡ implementafon ¡and ¡ different ¡CCA, ¡how ¡can ¡we ¡be ¡able ¡to ¡ performance ¡study ¡ manage ¡different ¡flows ¡and ¡"decide" ¡ the ¡best ¡opfons ¡for ¡each ¡of ¡them? ¡ Normal ¡server ¡ 4
NS-‑3 ¡+ ¡DCE ¡+ ¡LENA ¡project's ¡outcome ¡ For ¡the ¡model ¡ • For ¡end-‑nodes ¡(UEs ¡and ¡server) ¡ • • Direct ¡code ¡execufon ¡(DCE) ¡-‑> ¡emulated/virtualised ¡linux ¡machines ¡(from ¡real ¡ kernels) ¡ – Userspace ¡and ¡kernelspace ¡raw ¡code ¡execufon ¡ 5
First ¡decisions ¡to ¡simulate ¡a ¡"realisfc" ¡scenario ¡ The ¡point ¡was ¡to ¡get ¡drasfc ¡changes ¡in ¡terms ¡of ¡throughput. ¡How? ¡ Mobility ¡ model? ¡ P r o p a g a f o m n ¡ o d e l ? ¡ Fading ¡model ¡with ¡ traces? ¡ Ager ¡some ¡discussions ¡and ¡a ¡lot ¡of ¡troubleshoofng, ¡we ¡made ¡our ¡first ¡decisions ¡ among ¡all ¡the ¡opfons ¡offered ¡by ¡LTE/EPC ¡module ¡ 6
First ¡approach ¡ Tests ¡design ¡ Tests ¡shared ¡points ¡ • Proporfonal ¡Fair ¡scheduler ¡ 1. As ¡the ¡first ¡approach ¡the ¡UE ¡will ¡move, ¡ being ¡its ¡origin ¡the ¡EnodeB. ¡ • Fading ¡model ¡-‑ ¡EVA ¡(60 ¡km/h) ¡ 2. ¡Launch ¡wget ¡traffic ¡as ¡background ¡one. ¡ (long ¡file ¡download) ¡ • 2DRandom ¡mobility ¡model ¡ 3. Once ¡the ¡flow ¡is ¡established, ¡we ¡will ¡launch ¡ out ¡traces,modelling ¡different ¡behaviours ¡ • Single ¡cell ¡ (neUlix, ¡google ¡maps, ¡gaming, ¡web ¡page ¡and ¡ so ¡on). ¡ • 1 ¡UE. ¡AS ¡a ¡receiver ¡(as ¡background ¡traffic). ¡ 4. TCP's ¡different ¡flavours ¡are ¡used ¡in ¡this ¡ It ¡ will ¡ also ¡ be ¡ a ¡ foreground ¡ traffic ¡ (neUlix, ¡ regard. ¡ gaming ¡and ¡so ¡on) ¡receiver. ¡ 5. Capture ¡as ¡many ¡metrics ¡as ¡possible ¡to ¡try ¡ understanding ¡mostly ¡the ¡impact ¡on ¡ throughput ¡and ¡delay. ¡ 7
Preliminary ¡results ¡-‑ ¡NeUlix ¡& ¡Cubic ¡ Available vs used bandwidth ¡ Sum ¡of ¡throughputs. ¡ Throughput=Bytes/RTT ¡ High ¡probability ¡of ¡packet ¡ corrupfon, ¡retransmissions, ¡drop ¡ events, ¡... ¡ Let's ¡do ¡the ¡same, ¡but ¡with ¡more ¡TCP ¡flavours ¡!!! ¡ 8
NeUlix ¡as ¡foreground ¡traffic ¡(I) ¡ 10 CCA over Netflix model No ¡channel ¡losses ¡at ¡RLC ¡level ¡ 9
Macroscopic ¡approach ¡ • Inifal ¡conclusions ¡ – Huge ¡impact ¡of ¡schedulers/mobility ¡paTerns/number ¡of ¡users ¡per ¡cell ¡ – i.e. ¡PF ¡ • Real ¡achieved ¡throughput ¡or/and ¡consumed ¡RBs ¡ • Best ¡Transport ¡behaviour ¡may ¡result ¡on ¡lower ¡priority ¡ – Typical ¡metrics ¡not ¡that ¡useful ¡ • Proporfonal ¡Fair ¡scheduler ¡ • Fading ¡model ¡-‑ ¡EVA ¡(60 ¡km/h) ¡ • 2DRandom ¡mobility ¡model ¡ • Single ¡cell ¡ • 4 ¡UE. ¡All ¡of ¡them ¡as ¡receivers ¡(as ¡background ¡traffic). ¡One ¡of ¡them ¡ will ¡also ¡be ¡a ¡foreground ¡traffic ¡(neUlix, ¡gaming ¡and ¡so ¡on) ¡receiver. ¡ 10
Simulafons ¡results ¡-‑ ¡Macroscopic ¡view ¡(I) ¡ 4 ¡UE ¡moving ¡from ¡EnodeB ¡with ¡2DRandom ¡mobility ¡paTern ¡&& ¡100 ¡packets ¡queue ¡ • length ¡in ¡EnodeB ¡(I) ¡ As ¡expected, ¡cubic ¡gets ¡ the ¡highest ¡throughput ¡ but ¡being ¡affected ¡on ¡RTT. ¡ ¡ Regarding ¡the ¡RTT, ¡ westwood ¡performs ¡the ¡ best. ¡ 11
Simulafons ¡results ¡-‑ ¡Macroscopic ¡view ¡(II) ¡ 4 ¡UE ¡moving ¡from ¡EnodeB ¡with ¡2DRandom ¡mobility ¡paTern ¡&& ¡100 ¡packets ¡queue ¡ • length ¡in ¡EnodeB ¡(II) ¡ 12
Simulafons ¡results ¡-‑ ¡Macroscopic ¡view ¡(III) ¡ 13 ¡
Next ¡steps ¡ • Refining ¡mobile ¡broadband ¡traffic ¡mix ¡ • Compare ¡exisfng ¡transport ¡protocols ¡in ¡the ¡ emulated ¡scenario ¡ • Test ¡new ¡channel-‑aware ¡transport ¡protocols ¡ • Include ¡it ¡in ¡new ¡Scenarios ¡ 14 ¡
Current ¡Work ¡ 4G ¡/ ¡4G+ ¡opfmizafons ¡based ¡on ¡real-‑world ¡deployments ¡ QoE-‑driven ¡ (Parfal) ¡Channel-‑awareness ¡ Field ¡Tesfng ¡ CQI ¡traces ¡ Op#mal ¡eNodeB ¡scheduling ¡ GA, ¡MDP, ¡ 1s ¡to ¡2ms ¡granularity ¡ max(QoE) ¡subject ¡to ¡sum(RBs)<100 ¡ WhiTle, ¡ being ¡QoE=f{SBR} ¡and ¡SBR=f{RB,CQI} ¡ ¡ ¡ Giyngs… ¡ Experimental ¡ emulafon ¡ QoE-‑driven ¡ QoE=f{bitrate,energy} ¡ 15 ¡
Future ¡Work ¡ 4G+ ¡/ ¡5G ¡opfmizafons ¡ Parfal ¡ ¡ Cloud-‑RAN ¡ channel ¡ ¡ Channel ¡ ¡ Mobile ¡Edge ¡Compufng ¡ feedback ¡ feedback ¡ Op#miza#on ¡placed ¡close ¡to ¡eNodeB ¡ ¡ • eNodeB ¡with ¡less ¡complexity ¡ • ¡Server ¡instances ¡within ¡/ ¡close ¡to ¡RAN ¡ • ¡eNodeB ¡provides ¡(parfal) ¡channel ¡feedback ¡ 16 ¡
Recommend
More recommend
