Computer Network Protocols: Myths, Missteps, and Mysteries. Dr. Radia Perlman, Intel Fellow

Transcription

1 Computer Network Protocols: Myths, Missteps, and Mysteries Dr. Radia Perlman, Intel Fellow

2 It s not what you don t know that s the problem. It s what you do know that ain t true.mark Twain (?) 2

3 Network Protocols A lot of what everyone knows is false What is deployed is an accident of history, politics, mistakes The technology that wins out in the market is not necessarily the best There s a lot of unnecessary re-invention 3

4 How do you compare Technology Ask experts? A vs Technology B? But nobody knows both Measure for throughput, power, latency, etc? But you are only measuring one implementation of A vs one implementation of B And what is A or B. They are moving targets! 4

5 Teaching Computer Networks Usually taught as memorize the details of the currently deployed standards As if everything about it is perfect, no other ways ever existed Doesn t help students really understand The alternative Take a conceptual problem (like plugging into a network and getting an address), and discuss alternatives, with pros and cons Then you can give examples (e.g., IPv4, IPv6, Ethernet, IPX, Appletalk, ISO,.)

6 An Example: What is Ethernet? People think Ethernet is successful, since they use something called Ethernet But Ethernet as invented (in the early 1970 s) died out decades ago

7 CSMA/CD CSMA/CD was the Ethernet invention Lots of papers about its (CSMA/CD) performance, with various suggested variants CSMA/CD shared bus, peers, no master CS: carrier sense (don t interrupt) MA: multiple access (you re sharing the air!) CD: listen while talking, for collision 7

8 Strange History Ethernet was intended to be directly between neighbors on the same wire; not forwarded Another layer of networking was for forwarding between links ( layer 3, e.g., IP) But people got confused; built applications with network stacks without layer 3

9 Then People did want their applications to work on networks larger than CSMA/CD (single building, hundreds of nodes) Design constraint: can t change endnode behavior; can t change Ethernet packet in any way (including increasing the size)

10 Next Ethernet Idea; just move Ethernet packets around Learn location of endnodes based on (port, source address) so don t need to flood everything But only works if there are no loops Thus the spanning tree algorithm

11 A X,C J A X C E D 11

12 A Physical Topology X

13 A Pruned to Tree X

14 Algorhyme I think that I shall never see A graph more lovely than a tree. A tree whose crucial property Is loop-free connectivity. A tree which must be sure to span So packets can reach every LAN. First the root must be selected, By ID it is elected. Least cost paths from root are traced, In the tree these paths are placed. A mesh is made by folks like me. Then bridges find a spanning tree. 14 Radia Perlman

15 Why not just use IP routers? World has converged to IP as layer 3, and it s in the network stacks 15

16 Why not just use IP routers? IP is configuration intensive, moving VMs disruptive IP protocol requires every link to have a unique block of addresses Routers need to be configured with which addresses are on which ports If something moves, its address changes 16

17 Layer 3 doesn t have to work that way! CLNP / DECnet...20 byte address Bottom level of routing is a whole cloud with the same 14- byte prefix Routing is to 6 byte ID inside the cloud Enabled by ES-IS protocol, where endnodes periodically announce themselves to the routers 14 bytes 6 bytes Prefix shared by all nodes in large cloud Endnode ID 17

18 Hierarchy One prefix per link (like IP) One prefix per campus 292* 22* 28* 25* 293* 2* 2* 18

19 Worst decision ever 1992 Internet could have adopted CLNP Easier to move to a new layer 3 back then Internet smaller Not so mission critical IP hadn t yet (out of necessity) invented DHCP, NAT, so CLNP gave understandable advantages CLNP still has advantages over IPv6 (e.g., large multilink level 1 clouds) 19

20 Given IP, why we need Ethernet Ethernet provides a large cloud in which switches can autoconfigure, and nodes (e.g., VMs) can move around transparently But don t want limitations of spanning tree (the way Ethernet has worked for the last few decades) 20

21 Next step in evolution: TRILL 21

22 TRILL TRansparent Interconnection of Lots of Links Want best of both worlds From Ethernet: autoconfiguration, and flat address space From layer 3: Optimal paths, multipathing, traffic engineering, etc. 22

23 TRILL switches form network between themselves Run a (link state) routing protocol between the TRILL switches Spanning tree switches are just glue between TRILL switches So TRILL switches know how to reach other TRILL switches Put Ethernet packet into a layer 3-like header, addressing it to last switch 23

24 TRILL R4 R2 c R7 R3 R5 R6 a R1 24

25 TRILL packet Last switch 1st switch hops Original Ethernet packet TRILL header Switch addresses are 16 bits 25

26 16-bit TRILL switch nicknames Allows 64,000 switches many more endnodes TRILL autoconfigures nicknames Allows simple forwarding table lookup Direct table lookup Don t need associative memory, or hash, or longest prefix match 26

27 Advantage of extra header Switches inside cloud don t need to know about all the endnodes Forwarding table size of # of switches 27

28 Lessons What s out there is messy (just like the language English) But (so far) the industry has always managed to make it work, somehow Easier to publish papers with some sort of grand new architecture These seldom actually give us anything we can t already do Much easier to affect the world by being evolutionary (e.g., spanning tree, TRILL), or better implementations

29 My philosophy Networks should be auto-configuring If people want to configure things knobs should be optional, and any setting should still work! If possible, be evolutionary

30 Ideas for Research Tradeoff between flexibility/performance/power,cost Routers/switches used to be on general purpose machines Then bandwidth got too fast Today, possible again, and the concept is attractive for lots of reasons though what are the tradoffs

31 User authentication Ideas for Research

32 usability security 32

33 What you d expect usability security 33

34 What the world has achieved usability security 34

35 Ideas for Research Reputation (e.g., buying things online from strangers) Mysteriously, seems to mostly work Can it be subverted? How to protect against that?

36 Ideas for Research Limited wireless bandwidth It won t be universal And sometimes it s flaky Will we hit a wall in crowded places?

37 Thank you! 37