Computer Communication Networks Data Transmission Media Signal Encoding

Computer Communication Networks Data Transmission, Media Signal Encoding Techniques Data Communication Techniques Data Link Control, ATM Multiplexing, Switching, Routing Spread Spectrum, Wireless Networks Local and Wide Area Networks Transport Layer (UDP and TCP)

Lecture Goals Understand principles behind transport layer services: multiplexing/demultiplexing reliable data transfer flow control congestion control Implementation in the Internet 2

Lecture Overview Transport layer services Multiplexing/demultiplexing Connectionless transport: UDP Connection-oriented transport: TCP reliable transfer flow control connection management TCP congestion control 3

Transport services and protocols Provide logical communication between app’ processes running on different hosts Transport protocols run in end systems Transport vs. network layer services: network layer: data transfer between end systems transport layer: data transfer between processes Relies on, enhances, network layer services 4

Transport Services and Protocols application transport network data link physical al c gi lo network data link physical d en d- en network data link physical s an tr network data link physical rt po network data link physical application transport network data link physical 5

Transport-layer protocols Internet transport services: Reliable, in-order unicast delivery (TCP) congestion flow control connection setup Unreliable (“best-effort”), unordered unicast or multicast delivery: UDP Services not available: real-time bandwidth guarantees reliable multicast 6

Multiplexing / demultiplexing Recall: segment - unit of data exchanged between transport layer entities aka TPDU: transport protocol data unit application-layer data segment header segment Ht M Hn segment P 1 M application transport network P 3 Demultiplexing: delivering received segments to correct app layer processes receiver M M application transport network P 4 M P 2 application transport network 7

Multiplexing / demultiplexing Multiplexing: gathering data from multiple app processes, enveloping data with header (later used for demultiplexing) multiplexing/demultiplexing: based on sender, receiver port numbers, IP addresses source, dest port #s in each segment recall: well-known port numbers for specific applications 32 bits source port # dest port # other header fields application data (message) TCP/UDP segment format 8

Multiplexing/demultiplexing: examples host A source port: x dest. port: 23 server B source port: 23 dest. port: x Source IP: C Dest IP: B source port: y dest. port: 80 port use: simple telnet app Web client host A Web client host C Source IP: A Dest IP: B source port: x dest. port: 80 Source IP: C Dest IP: B source port: x dest. port: 80 Web server B port use: Web server 9

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: no handshaking between UDP sender, receiver each UDP segment handled independently of others 10

UDP: User Datagram Protocol [RFC 768] 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. May not be a good idea, though! 11

UDP: more Often used for streaming multimedia apps loss tolerant rate sensitive Other UDP uses (why? ): DNS SNMP Reliable transfer over UDP: add reliability at application layer application-specific error recovery! 12

UDP: more 32 bits Length, in bytes of UDP segment, including header source port # dest port # length checksum Application data (message) UDP segment format 13

Parity Checks 10111010 1 2 3 4 5 6 7 8 9 Odd Parity 10111010 0 001110100 1 2 3 4 5 6 7 89 1 -bit error 000100100 00011010 0 1 2 3 4 5 6 7 89 3 -bit error Even Parity 1 2 3 4 5 6 7 89 2 -bit error 10110 1 2 3 4 5 6 7 89 Parity can detect 1 -bit errors 14

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 15

UDP checksum 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? 16

UDP Servers Most UDP servers are “iterative” => a single server process receives and handles incoming requests on a “well-known” port. Can filter client requests based on incoming IP/port addresses or wild card filters Port numbers may be reused, but packet is delivered to at most one end-point. Queues to hold requests if server busy 17

Principles of Reliable Data Transfer Important in app. , transport, link layers top-10 list of important networking topics! • Characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt) 18

Reliability mechanisms… Mechanisms: Checksum in pkts: detects pkt corruption ACK: “packet correctly received” NAK: “packet incorrectly received” [aka: stop-and-wait Automatic Repeat re. Quest (ARQ) protocols] Reliability capabilities achieved: An error-free channel A forward channel which has bit-errors 19

TCP: Overview Point-to-point: one sender, one receiver Reliable, in-order byte steam: no “message boundaries” But TCP chops it up into segments for transmission internally Pipelined (window) flow control: Window size decided by receiver and network Send & receive buffers 20

TCP: Overview 21

TCP: Overview Full duplex data: bi-directional data flow in same connection MSS: maximum segment size Connection-oriented: handshaking (exchange of control msgs) init’s sender, receiver state before data exchange Flow & Congestion Control: sender will not overwhelm receiver or the network 22

TCP segment structure 32 bits 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) source port # dest port # sequence number acknowledgement number head not U AP R S F len used checksum rcvr window size ptr urgent data Options (variable length) counting by bytes of data (not segments!) # bytes rcvr willing to accept application data (variable length) 23

TCP seq. #’s and ACKs (I) Sequence Numbers: byte stream “number” of first byte in segment’s data ACKs: seq # of next byte expected from other side cumulative ACK Q: how receiver handles out-of-order segments A: TCP spec doesn’t say, - up to implementor 24

TCP Seq. #’s and ACKs (II) Host B Host A User types ‘C’ Seq=4 2, ACK =79, d ata = ‘ K=4 C A , =79 ta = 3, da Seq host ACKs receipt of echoed ‘C’ Seq=4 C’ ‘C’ host ACKs receipt of ‘C’, echoes back ‘C’ 3, ACK =80 simple telnet scenario 25

Temporal Redundancy Model Packets • Sequence Numbers • CRC or Checksum Timeout Status Reports • ACKs • NAKs, Retransmissions • Packets • FEC information 26

Status Report Design Cumulative acks: Robust to losses on the reverse channel Cannot pinpoint blocks of data which are lost The first lost packet can be pinpointed because the receiver would generate duplicate acks 27

TCP ACK generation Event TCP Receiver action in-order segment arrival, no gaps, everything else already ACKed delayed ACK. Wait up to 500 ms for next segment. If no next segment, send ACK in-order segment arrival, no gaps, one delayed ACK pending immediately send single cumulative ACK out-of-order segment arrival higher-than-expect seq. # gap detected! send duplicate ACK, indicating seq. # of next expected byte 28

TCP: retransmission scenarios Host A 2, 8 by tes da ta =100 ACK X loss Seq=9 2, 8 by tes da ta a 100, 2 0 byt es da ta 0 10 = K 20 AC CK=1 A Seq=9 2, 8 by tes da ta 0 =100 lost ACK scenario Seq= 2, 8 by tes da t 12 K= AC ACK time Host B Seq=9 Seq=100 timeout Seq=92 timeout Seq=9 timeout Host A Host B time premature timeout, cumulative ACKs 29

TCP Flow Control flow control sender won’t overrun receiver’s buffers by transmitting too much, too fast Rcv. Buffer = size or TCP Receive Buffer Rcv. Window = amount of spare room in Buffer receiver: explicitly informs sender of free buffer space Rcv. Window field in TCP segment sender: keeps the amount of transmitted, un. ACKed data less than most recently received Rcv. Window receiver buffering 30

TCP Connection Management - 1 Recall: TCP sender, receiver establish connection before exchanging data segments initialize TCP variables: seq. #s buffers, flow control info (e. g. Rcv. Window) client: connection initiator Socket client. Socket = new Socket("hostname", "port number"); server: contacted by client Socket connection. Socket = server. Socket. accept(); 31

TCP Connection Management - 2 Three way handshake: Step 1: client end system sends TCP SYN control segment to server specifies initial seq # Step 2: server end system receives SYN, replies with SYNACK control segment ACKs received SYN allocates buffers specifies server-> receiver initial seq. # 32

TCP Connection Management - 3 Closing a connection: client closes socket: client. Socket. close(); Step 1: client end system sends TCP FIN control segment to server Step 2: server receives FIN, replies with ACK. Closes connection, sends FIN. 33

TCP Connection Management - 4 Fddfdf client close server FIN ACK close d timed wait FIN ACK closed 34

TCP Connection Management - 5 Step 3: client receives FIN, replies with ACK. Enters “timed wait” - will respond with ACK to received FINs Step 4: server, receives ACK. Connection closed. Note: with small modification, can handle simultaneous FINs. 35

The Congestion Problems: Incomplete information (eg: loss indications) Distributed solution required Congestion and control/measurement locations different Time-varying delays 36

The Congestion Problem Static fixes may not solve congestion a) Memory becomes cheap (infinite memory) No buffer q Too late b) Links become cheap (high speed links)? Replace with 1 Mb/s All links 19. 2 kb/s S S S File Transfer time = 5 mins S S File Transfer Time = 7 hours S

The Congestion Problem (Continued) c) Processors become cheap (resulting in faster routers & switches) A B S C D Scenario: All links 1 Gb/s. A & B send to C => “high-speed” congestion!! (lose more packets faster!)

Principles of Congestion Control Congestion: informally: “too many sources sending too much data too fast for network to handle” different from flow control (receiver overload)! symptoms: lost packets (buffer overflow at routers) long delays (queuing in router buffers) a top-10 problem! 39

Causes/costs of congestion: scenario 1 two senders, two receivers one router, infinite buffers no retransmission • • large delays when congested maximum achievable throughput 40

Causes/costs of congestion: scenario 2 one router, finite buffers sender retransmission of lost packet 41

Causes/costs of congestion: scenario 2 (continued) “Costs” of congestion: More work (retrans) for given “goodput” Unneeded retransmissions: link carries multiple copies of pkt due to spurious timeouts 42

Causes/costs of congestion: scenario 3 Another “cost” of congestion: when packet dropped, any “upstream transmission capacity used for that packet wasted! 43

Approaches towards congestion control - 1 Two broad approaches towards congestion control: End-end congestion control: no explicit feedback from network congestion inferred from end-system observed loss, delay approach taken by TCP 44

Approaches towards congestion control - 2 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 45

TCP congestion control - 1 end-end control (no network assistance) transmission rate limited by congestion window size, Congwin, over segments: 46

TCP congestion control - 2 “Probing” for usable bandwidth: Window flow control: avoid receiver overrun Dynamic window congestion control: avoid/control network overrun Policy: Increase Congwin until loss (congestion) Loss => decrease Congwin, then begin probing (increasing) again 47

Additive Increase/Multiplicative Decrease (AIMD) Policy For stability: rate-of-decrease > rate-of-increase Decrease performed “enough” times as long as congestion exists AIMD policy satisfies this condition, provided packet loss is congestion indicator window time 48

Fairness goal: if N TCP sessions share same bottleneck link, each should get 1/N of link capacity TCP connection 1 TCP connection 2 bottleneck router capacity R 49

TCP latency Q: How long does it take to receive an object from a Web server after sending a request? TCP connection establishment data transfer delay 50

Summary • Principles behind transport layer services: • multiplexing/demultiplexing • reliable data transfer • flow control • congestion control • Instantiation and implementation in the Internet • UDP, TCP 51

Q&A ?