ϔομʔͦͷͷѹॖ͞Ε͍ͯͳ͍ͨΊɺখ͞ͳσʔλΛసૹ͢Δ߹ɺϔομʔ͕ඇѹॖ Ͱ͋Δ͜ͱͰσʔλྔ͕૿͑ɺసૹ͕͘ͳΔ͜ͱ͕ࢄݟ w 41%:ʹ͓͚Δѹॖ w [MJCʹΑΔϔομʔશମͷѹॖ 41%:Ͱ[MJCΛ༻͍ͯϔομʔͦͷͷΛѹॖ͢Δ͜ͱͰσʔλྔΛݮ w $3*.&߈ܸ 41%:5-4ʹΑΓ҉߸Խ͞Ε͍ͯΔͷͷɺ[MJCͳͲͰѹॖΛߦΘΕ͍ͯΔ߹ɺಉ͡σʔλ Λ࠶ૹ͢Δ͜ͱͰ҉߸ڧ͕Լ͕Γɺ࣮ࡍʹ5-4Ͱ҉߸Խ͞Εͨ41%:ϔομʔͷղಡ͕ՄೳͰ ͋Δ͜ͱ͕ূ໌͞Εͨɻ͜ͷ͜ͱʹΑΓɺϔομʔΛ୯७ѹॖ͢Δ͜ͱͰσʔλྔͷݮʹ ܨ͕Δͷͷɺ੬ऑͰ͋Δ͜ͱ͕ূ໌͞ΕΔ
w TUBUJDUBCMFͱEZOBNJDUBCMFΛ༻͍ͨදݱ ͋Β͔͡Ί6TFS"HFOUͳͲҰൠతʹΘΕΔϔομʔཁૉΛαʔόΫϥΠΞϯτͰ ఆٛ͠ɺϔομʔ൪߸Λ༻͍ͯදݱ͢Δ͜ͱͰσʔλྔΛݮ͢Δ w ࠩͷΈΛૹ৴͢Δ $3*.&߈ܸͰॏෳͨ͠σʔλΛૹ৴͢Δ͜ͱͰ҉߸ڧ͕Լ͕Γɺσʔλ͕ղੳ ՄೳͰ͋ͬͨɻͦͷͨΊɺ)1"$,Ͱલʹૹ৴ͨ͠ϦΫΤετ͔ΒͷࠩͷΈΛ௨ ৴͢Δ͜ͱͰॏෳͨ͠σʔλͷૹ৴Λආ͚ɺ$3*.&߈ܸΛ͚͞Δ͜ͱ͕ՄೳͱͳΔ
All Middleboxes L3 Routers L2 Switches IP Firewalls App. Firewalls Wan Opt. Proxies App. Gateways VPNs Load Balancers IDS/IPS Very Large Large Medium Small Figure 1: Box plot of middlebox deployments for small (fewer than 1k hosts), medium (1k-10k hosts), large (10k-100k hosts), and very large (more than 100k hosts) enterprise networks. Y-axis is in log scale. 2.2 Complexity in Management Figure 1 also shows that middleboxes deployments are diverse. Of the eight middlebox categories we present in Figure 1, the me- dian very large network deployed seven categories of middleboxes, and the median small network deployed middleboxes from four. Our categories are coarse-grained (e.g. Application Gateways in- clude smartphone proxies and VoIP gateways), so these figures rep- resent a lower bound on the number of distinct device types in the network. Managing many heterogeneous devices requires broad expertise and consequently a large management team. Figure 3 correlates the number of middleboxes against the number of networking person- nel. Even small networks with only tens of middleboxes typically required a management team of 6-25 personnel. Thus, middlebox deployments incur substantial operational expenses in addition to hardware costs. Understanding the administrative tasks involved further illumi- nates why large administrative staffs are needed. We break down the management tasks related to middleboxes below. Upgrades and Vendor Interaction. Deploying new features in the network entails deploying new hardware infrastructure. From our Misconfig. Overload Physical/Electric Firewalls 67.3% 16.3% 16.3% Proxies 63.2% 15.7% 21.1% IDS 54.5% 11.4% 34% Table 1: Fraction of network administrators who estimated misconfiguration, overload, or physical/electrical failure as the most common cause of middlebox failure. icy goals (e.g. a HTTP application filter may block social network sites). Cloud-based deployments obviate the need for enterprise administrators to focus on the low-level mechanisms for appliance configuration and focus only on policy configuration. Training. New appliances require new training for administrators to manage them. One administrator even stated that existing train- ing and expertise was a key question in purchasing decisions: Do we have the expertise necessary to use the product, or would we have to invest significant resources to use it? Another administrator reports that a lack of training limits the ben- efits from use of middleboxes: The average very large network in our data set hosts 2850 L3 routers, and 1946 total middleboxes; the average small network in our data set hosts 7.3 L3 routers and 10.2 total middleboxes. • Almost same # of middle box as routers • # of MiddleBox > # of Router in Small Network 4IFSSZ +VTUJOF FUBM.BLJOHNJEEMFCPYFTTPNFPOFFMTFTQSPCMFNOFUXPSLQSPDFTTJOH BTBDMPVETFSWJDF1SPDFFEJOHTPGUIF"$.4*($0..DPOGFSFODF"$.
flesh out a design for a tunneling protocol, running atop UDP, which can multiplex a large number of streams between two endpoints… The eventual protocol may likely strongly resemble SCTP, using encryption strongly resembling DTLS, running atop UDP.” “Why can’t you just evolve and improve TCP under SPDY? - That is our goal. TCP support is built into the kernel of operating systems. Considering how slowly users around the world upgrade their OS, it is unlikely to see significant adoption of client-side TCP changes in less than 5-15 years. QUIC allows us to test and experiment with new ideas, and to get results sooner. We are hopeful that QUIC features will migrate into TCP and TLS if they prove effective.”
Destination R1 R2 Cellular Line WiFi Fixed Line Wireless Nodes rmnet0 192.0.2.23 wlan0 203.0.133.24 Home ISP • Every QUIC session has a Connection-ID. • Clients can resume connection using Connection-ID • No need to re-establish connection
also defined for P2P data connection • SCTP over DTLS over UDP with ICE NAT support • Low latency, P2P connections for browser • Configurable in-order or out-order delivery • 4 RTT for handshake 'JHVSFTBSFGSPN)JHI1FSGPSNBODF#SPXTFS/FUXPSLJOH7FMPDJUZ*MZB(SJHPSJL
to current TCP • Protocols/hacks are proposed to speed up without breaking current internet or trying to reflect feedback from “TCP alternative” protocols. • Multipath TCP • TCP Fast Open • TLS Snap Start • FEC in TCP • TCP Crypto
w 6%1Ͱ͏߹%5-4Λ༻͍Δ w ݱࡏ5-4ͷࡦఆத w ϋϯυγΣΠΫखॱͷ؆ུԽ<5-4'BMTF4UBSU><> w ݤަΞϧΰϦζϜͷมߋ <>/FX)BOETIBLF'MPXTGPS5-4<IUUQTEBUBUSBDLFSJFUGPSHEPDESBGUSFTDPSMBUMTOFXqPXT>
w $$4*OKFDUJPO $ISPNJVN͕0QFO44-ͱ͔ʹͳΔΒ͍͠Ͱ͢Α<> w 3$ͷةຆԽ<> w 1'4ͷॏཁੑ <>ετϦʔϜ҉߸3$ͷ҆શੑධՁ<IUUQXXXDSZQUSFDHPKQFTUJNBUJPOUFDISFQ@JEQEG> <>$ISPNF'SPN/44UP0QFO44-<IUUQTEPDTHPPHMFDPNEPDVNFOUE .-;ZZ.QO"SDM*"X8S9%Q2H/3%QQ.:XU9W&TFEJU>
͔͠͠*41Ϋϥυࣄۀऀʹ·ͩࡏݿ͕͋Δʜ w .JDSPTPGU"[VSF 64SFHJPOʹ͓͍ͯ64*1WΞυϨε͕ރׇ<> w *1WΞυϨεͷചങ+1/*$Ͱطʹ݅<> <>IUUQB[VSFNJDSPTPGUDPNCMPHXJOEPXTB[VSFTVTFPGOPOVTJQW BEESFTTTQBDFJOVTSFHJPOT <>IUUQTXXXOJDBEKQKBJQJQWUSBOTGFSMPHIUNM
Hirotaka Nakajima
nunnun
taichinakamura
satoshishibata0108
futayamaji
fill9120
line_developers
hololab
clustervr
line_developers_tw
cmusudakeisuke
harshbothra
sonnylazuardi
nk35jk
malarkey
hatefulcrawdad
scottboms
tanoku
kastner
jensimmons
jeffersonlam
schacon
chriscoyier
geeforr
sachag
maggiecrowley
