Application. Transport. Network. Link. Physical

Transcription

1 Transport Layer ELEC1200 Principles behind transport layer services Multiplexing and demultiplexing UDP TCP Reliable Data Transfer TCP Congestion Control TCP Fairness *The slides are adapted from ppt slides (in substantially unaltered form) available from Computer Networking: A Top-Down Approach, 4 th edition, by Jim Kurose and Keith Ross, Addison-Wesley, July Part of the materials are also adapted from ELEC315 and MIT 6.02 course notes. 1

2 Internet protocol stack application: supporting applications HTTP, SMTP, FTP, DNS transport: process-process data transfer TCP, UDP : routing of datagrams from source to destination IP, routing protocols link: data transfer between neighboring elements , Ethernett : bits on the wire Application Transport Network Link Physical 2

3 Transport services and protocols application transport provide logical communication data link between app processes running on different hosts transport protocols run in end systems send side: breaks app messages into segments, passes to layer rcv side: reassembles application transport segments into messages, data link passes to app layer more than one transport t protocol available to apps Internet: TCP and UDP 3

4 Internet transport-layer protocols reliable, in-order delivery (TCP) congestion control flow control connection setup unreliable, unordered d delivery: UDP no-frills extension of best-effort IP services not available: delay guarantees bandwidth guarantees application transport data link data link data link data link data link data link data link application transport data link 4

5 Multiplexing/demultiplexing Demultiplexing at rcv host: delivering received segments to correct socket = socket = process Multiplexing at send host: gathering data from multiple l sockets, enveloping data with header (later used for demultiplexing) Socket: a door between application process and end-end- transport protocol (UDP or TCP) application P3 P1 P1 application P2 P4 application transport link transport link transport link host 1 host 2 host 3 5

6 How demultiplexing works host receives IP datagrams each datagram has source 32 bits IP address, destination IP address source port # dest port # each datagram carries 1 transport-layer segment each segment has source, destination port number other header fields host uses IP addresses & port application numbers to direct segment to data appropriate socket (message) TCP/UDP segment format 6

7 UDP: User Datagram Protocol [RFC 768] no frills, bare bones Internet transport protocol best effort service, UDP segments may be: lost delivered out of order to app connectionless: nl no handshaking between UDP sender, receiver each UDP segment handled independently of others Why is there a UDP? no connection establishment (which can add delay) simple: no connection state at sender, receiver small segment header no congestion control: UDP can blast away as fast as desired 7

8 UDP: more often used for streaming multimedia apps 32 bits loss tolerant source port # dest port # rate sensitive other UDP uses Length, in bytes of UDP segment, including header length DNS SNMP reliable transfer over UDP: Application add reliability at data application layer (message) application-specific ifi error recovery! checksum UDP segment format 8

9 UDP checksum Goal: detect errors (e.g., flipped bits) in transmitted segment Sender: treat segment contents as sequence of 16-bit integers checksum: addition (1 s complement sum) of segment contents sender puts checksum value into UDP checksum field Receiver: compute checksum of received segment check if computed checksum equals checksum field value: NO - error detected YES - no error detected. But maybe errors nonetheless? More later. 9

10 TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581 socket door point-to-point: t i t: full duplex data: one sender, one receiver bi-directional data flow in same connection reliable, in-order byte in same connection stream: no message boundaries pipelined: TCP congestion and flow control set window size send & receive buffers application writes data TCP send buffer segment application reads data TCP receive buffer socket door MSS: maximum segment size connection-oriented: handshaking (exchange of control msgs) init s sender, receiver state before data exchange flow controlled: sender will not overwhelm receiver 10

11 TCP segment structure URG: urgent data (generally not used) ACK: ACK # valid PSH: push data now (generally not used) RST, SYN, FIN: connection estab (setup, teardown commands) Internet checksum (as in UDP) 32 bits source port # dest port # head len sequence number acknowledgement number not used UAP R S F checksum Receive window Urg data pnter Options (variable length) application data (variable length) counting by bytes of data (not segments!) # bytes rcvr willing to accept 11

12 Principles of Reliable data transfer important in app., transport, link layers top-10 list of important ing topics! characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt) 12

13 Stop-and-wait & Pipelined protocols Pipelining: sender allows multiple, in-flight, yet-to- be-acknowledged pkts range of sequence numbers must be increased buffering at sender and/or receiver Two generic forms of pipelined protocols: go-back-n, selective repeat 13

14 Stop-and-wait protocol first bit transmitted, t = 0 last bit transmitted, t = L / R RTT sender receiver first packet bit arrives last packet bit arrives, send ACK ACK arrives, send next packet, t = RTT + L / R Assume L/R = ms and RTT = 30 ms U sender = L / R RTT + L / R = = Transport Layer 14

15 Pipelining: increased utilization sender first packet bit transmitted, t = 0 last bit transmitted, t = L / R receiver RTT ACK arrives, send next packet, t = RTT + L / R first packet bit arrives last packet bit arrives, send ACK last bit of 2 nd packet arrives, send ACK last bit of 3 rd packet arrives, send ACK Increase utilization by a factor of 3! U sender = 3 * L / R RTT + L / R = =

16 Principles of Congestion Control Congestion: informally: too many sources sending too much data too fast for to handle manifestations: lost packets (buffer overflow at routers) long delays (queueing in router buffers) a top-10 problem! 16

17 Approaches towards congestion control Two broad approaches towards congestion control: End-end congestion control: no explicit feedback from congestion inferred from end-system observed loss, delay approach taken by TCP Network-assisted congestion control: routers provide feedback to end systems single bit indicating congestion (SNA, DECbit, TCP/IP ECN, ATM) explicit rate sender should send at 17

18 TCP congestion control: additive increase, multiplicative decrease Approach: increase transmission ss rate (window size), probing for usable bandwidth, until loss occurs rate = CongWin RTT Bytes/sec additive increase: increase CongWin by 1 MSS every RTT until loss detected multiplicative decrease: cut CongWin in half after congestion loss window Saw tooth behavior: probing for bandwidth size congestion n window 24 Kbytes 16 Kbytes 8 Kbytes time Transport Layer 17

19 TCP Fairness Fairness goal: if K TCP sessions share same bottleneck link of bandwidth R, each should have average rate of R/K TCP connection 1 TCP connection 2 bottleneck router capacity R 19

20 Why is TCP fair? Two competing TCP connections: Additive increase gives slope of 1, as throughout (rate) increases Multiplicative decrease decreases throughput proportionally R equal bandwidth share loss: decrease window by factor of 2 congestion avoidance: additive i increase loss: decrease window by factor of 2 congestion avoidance: additive increase Connection 1 throughput h R Transport Layer 20

21 Fairness (more) Fairness and UDP Multimedia apps often do not use TCP do not want rate throttled by congestion control Instead use UDP: pump audio/video at constant rate, tolerate packet loss Fairness and parallel TCP connections nothing prevents app from opening parallel connections between 2 hosts. Web browsers do this Example: link of rate R supporting 9 connections; new app asks for 1 TCP, gets Research area: TCP rate R/10 friendly new app asks for 11 TCPs, gets R/2! 21

22 Summary Principles behind transport layer services: multiplexing, demultiplexing reliable data transfer flow control congestion control Internet provides two transport protocols UDP TCP 22