Wrapping Up IP + The Transport Layer

1. Wrapping Up IP+The Transport Layer EE 122, Fall 2013 Sylvia Ratnasamy http://inst.eecs.berkeley.edu/~ee122/ Material thanks to Ion Stoica, Scott Shenker, Jennifer Rexford, Nick McKeown, and many other colleagues

2. Last Lecture: IP Routers Route/Control Processor Linecards (input) Linecards (output) 1 1 2 2 InterconnectFabric N N

3. CPU Buffer Memory Route Table CPU Line Interface Line Interface Line Interface Memory MAC MAC MAC Shared Memory (1st Generation) Shared Backplane Linecard Limited by rate of shared memory (* Slide by Nick McKeown, Stanford Univ.)

4. Fwding Cache Shared Bus (2nd Generation) CPU Buffer Memory Route Table Line Card Line Card Line Card Limited by shared bus Buffer Memory Buffer Memory Buffer Memory Fwding Cache Fwding Cache MAC MAC MAC (* Slide by Nick McKeown)

5. Switched Backplane Line Card CPU Card Line Card Local Buffer Memory Local Buffer Memory Routing Table CPU Line Interface Memory Fwding Table Fwding Table MAC MAC Point-to-Point Switch (3rd Generation) (*Slide by Nick McKeown)

6. 3rdGen. Router: Switched Interconnects NxR This is called an “output queued” switch

7. 3rd Gen. Router: Switched Interconnects This is called an “input queued” switch

8. Two challenges with input queuing 1) Need an internal fabric scheduler!

9. 3rd Gen. Router: Switched Interconnects Fabric Scheduler

10. Two challenges with input queuing • Need an internal fabric scheduler! • Must avoid “head-of-line” blocking

11. Head of Line Blocking HoL blocking limits throughput to approximately 58% of capacity

12. “Virtual Output Queues”

13. 1 x R 3rd Gen. Router: Switched Interconnects Fabric Scheduler

14. Reality is more complicated • Commercial (high-speed) routers use • combination of input and output queuing • complex multi-stage switching topologies (Clos, Benes) • distributed, multi-stage schedulers (for scalability) • We’ll consider one simpler context • de-facto architecture for a long time and still used in lower-speed routers

15. Context • Crossbar fabric • Centralized scheduler Input ports Output ports

16. Scheduling • Goal: run links at full capacity, fairness across inputs • Scheduling formulated as finding a matching on a bipartite graph • Practical solutions look for a good maximalmatching (fast) Input ports Outputports

17. The Transport Layer

18. Application Application From Lecture#3: Transport Layer • Layer at end-hosts, between the application and network layer Transport Transport Network Network Network Datalink Datalink Datalink Physical Physical Physical Router Host B Host A

19. Why a transport layer? • IP packets are addressed to a host but end-to-end communication is between application processes at hosts • Need a way to decide which packets go to which applications (multiplexing/demultiplexing)

20. Application Application Why a transport layer? Transport Transport Network Network Datalink Datalink Physical Physical Host B Host A

21. Application Why a transport layer? many application processes ftp telnet browser browser mmedia Transport Operating System Network Datalink IP Physical Datalink Physical Drivers+NIC Host B Host A

22. Why a transport layer? many application processes HTTP server ftp ftp telnet telnet browser browser mmedia Transport Transport IP IP Datalink Physical Datalink Physical Communication between hosts (128.4.5.6 162.99.7.56) Communication between processes at hosts Host B Host A

23. Why a transport layer? • IP packets are addressed to a host but end-to-end communication is between application processes at hosts • Needa way to decide which packets go to which applications (mux/demux) • IP provides a weak service model (best-effort) • Packets can be corrupted, delayed, dropped, reordered, duplicated • No guidance on how much traffic to send and when • Dealing with this is tedious for application developers

24. Role of the Transport Layer • Communication between application processes • Mux and demux from/to application processes • Implemented using ports

25. Role of the Transport Layer • Communication between application processes • Provide common end-to-end services for app layer [optional] • Reliable, in-order data delivery • Well-paced data delivery • too fast may overwhelm the network • too slow is not efficient

26. Role of the Transport Layer • Communication between processes • Provide common end-to-end services for app layer [optional] • TCP and UDP are the common transport protocols • also SCTP, MTCP, SST, RDP, DCCP, …

27. Role of the Transport Layer • Communication between processes • Provide common end-to-end services for app layer [optional] • TCP and UDP are the common transport protocols • UDP is a minimalist, no-frills transport protocol • only provides mux/demux capabilities

28. Role of the Transport Layer • Communication between processes • Provide common end-to-end services for app layer [optional] • TCP and UDP are the common transport protocols • UDP is a minimalist, no-frills transport protocol • TCP is the whole-hog protocol • offers apps a reliable, in-order, bytestream abstraction • with congestion control • but no performance guarantees (delay, bw, etc.)

29. Role of the Transport Layer • Communication between processes • mux/demux from and to application processes • implemented using ports

30. Context: Applications and Sockets • Socket: software abstraction by which an application process exchanges network messages with the (transport layer in the) operating system • socketID = socket(…, socket.TYPE) • socketID.sendto(message, …) • socketID.recvfrom(…) • will cover in detail after midterm • Two important types of sockets • UDP socket: TYPE is SOCK_DGRAM • TCP socket: TYPE is SOCK_STREAM

31. Ports • Problem: deciding which app (socket) gets which packets • Solution: portas a transport layer identifier • 16 bit identifier • OS stores mapping between sockets and ports • a packet carries a source and destination port number in itstransport layer header • For UDP ports (SOCK_DGRAM) • OS stores (local port, local IP address)  socket • For TCP ports (SOCK_STREAM) • OS stores (local port, local IP, remote port, remote IP)  socket

32. 4-bit Header Length 8-bit Type of Service (TOS) 4-bit Version 16-bit Total Length (Bytes) 3-bit Flags 16-bit Identification 13-bit Fragment Offset 8-bit Time to Live (TTL) 8-bit Protocol 16-bit Header Checksum 32-bit Source IP Address 32-bit Destination IP Address Options (if any) Payload

33. 8-bit Type of Service (TOS) 5 4 16-bit Total Length (Bytes) 3-bit Flags 16-bit Identification 13-bit Fragment Offset 8-bit Time to Live (TTL) 8-bit Protocol 16-bit Header Checksum 32-bit Source IP Address 32-bit Destination IP Address Payload

34. 8-bit Type of Service (TOS) 5 4 16-bit Total Length (Bytes) 3-bit Flags 16-bit Identification 13-bit Fragment Offset 8-bit Time to Live (TTL) 6 = TCP17 = UDP 16-bit Header Checksum 32-bit Source IP Address 32-bit Destination IP Address Payload

35. 8-bit Type of Service (TOS) 5 4 16-bit Total Length (Bytes) 3-bit Flags 16-bit Identification 13-bit Fragment Offset 8-bit Time to Live (TTL) 6 = TCP17 = UDP 16-bit Header Checksum 32-bit Source IP Address 32-bit Destination IP Address 16-bit Source Port 16-bit Destination Port More transport header fields …. Payload

36. Host receives IP packets Each IP header has source and destination IP address Each Transport Layer header has source and destination port number Host uses IP addresses and port numbers to direct the message to appropriate socket Recap: Multiplexing and Demultiplexing

37. More on Ports • Separate 16-bit port address space for UDP and TCP • “Well known” ports(0-1023): everyone agrees whichservices run on these ports • e.g., ssh:22, http:80 • helps client know server’s port • Ephemeral ports (most 1024-65535): given to clients

38. UDP: User Datagram Protocol • Lightweight communication between processes • Avoid overhead and delays of ordered, reliable delivery • UDP described in RFC 768 – (1980!) • Destination IP address and port to support demultiplexing • Optional error checking on the packet contents • (checksum field = 0 means “don’t verify checksum”) SRC port DST port checksum length DATA

39. Why a transport layer? • IP packets are addressed to a host but end-to-end communication is between application processes at hosts • Needa way to decide which packets go to which applications (mux/demux) • IP provides a weak service model (best-effort) • Packets can be corrupted, delayed, dropped, reordered, duplicated

40. Announcements • The next 2-3 weeks will be the hardest of this class • Project#1 due; Project #2 out • HW#2 out • Midterm • If you’re struggling, ask for help early ! • Attend TA’s extra office hours close to project deadlines

41. Reliable Transport @Sender • send packets @Receiver • wait for packets • In a perfect world, reliable transport is easy

42. Reliable Transport • In a perfect world, reliable transport is easy • All the bad things best-effort can do • a packet is corrupted (bit errors) • a packet is lost • a packet is delayed (why?) • packets are reordered (why?) • a packet is duplicated (why?)

43. Dealing with Packet Corruption 1  ack 2  nack . . . 2 Sender Receiver Time

44. Dealing with Packet Corruption 1 P(1)  ack(1)  1 P(1) Packet #1 or #2? ack(1) 2 P(2) Data and ACK packets carry sequence numbers What if the ACK/NACK is corrupted? Sender Receiver Time

45. Timeout Dealing with Packet Loss 1 P(1)  1 P(1) ack(1) P(2) Sender Receiver Timer-driven loss detectionSet timer when packet is sent; retransmit on timeout Time

46. Timeout Dealing with Packet Loss 1 P(1)  1 P(1) duplicate! ack(1) P(2) Sender Receiver Time

47. Timeout Dealing with Packet Loss 1 P(1) ack(1) 1 P(1) duplicate! . . . ack(1) P(2) Sender Receiver Timer-driven retx. can lead to duplicates Time

48. Components of a solution (so far) • checksums (to detect bit errors) • timers (to detect loss) • acknowledgements (positive or negative) • sequence numbers (to deal with duplicates)

49. A Solution: “Stop and Wait” • We have a correct reliable transport protocol! • Probably the world’s most inefficient one… @Sender • send packet(I); (re)set timer; wait for ack • If (ACK) • I++; repeat • If (NACK or TIMEOUT) • repeat @Receiver • wait for packet • if packet is OK, send ACK • else, send NACK • repeat

50. Stop & Wait is Inefficient TRANS DATA RTT Inefficient if TRANS << RTT ACK Receiver Sender