Data Communication and Networks Lecture 9 10 Internet Protocols

Data Communication and Networks Lecture 9/10 Internet Protocols November 6, 2003 Joseph Conron Computer Science Department New York University jconron@cs. nyu. edu

What’s the Internet: Components view z millions of connected computing devices: hosts, endsystems y pc’s workstations, servers y PDA’s phones, toasters running network apps z communication links y fiber, copper, radio, satellite z routers: forward packets (chunks) of data thru network

What’s the Internet: Components view z protocols: control sending, receiving of msgs y e. g. , TCP, IP, HTTP, FTP, PPP z Internet: “network of networks” y loosely hierarchical y public Internet versus private intranet z Internet standards y RFC: Request for comments y IETF: Internet Engineering Task Force

What’s the Internet: a service view z communication infrastructure enables distributed applications: y WWW, email, games, e-commerce, database. , voting, y more? z communication services provided: y connectionless y connection-oriented

Internet structure: network of networks z roughly hierarchical z national/international backbone providers (NBPs) y e. g. BBN/GTE, Sprint, AT&T, IBM, UUNet y interconnect (peer) with each other privately, or at public Network Access Point (NAPs) z regional ISPs y connect into NBPs z local ISP, company y connect into regional ISPs local ISP regional ISP NBP B NAP NBP A regional ISP local ISP

Connectionless Operation z Corresponds to datagram mechanism in packet switched network z Each NPDU treated separately z Network layer protocol common to all DTEs and routers y Known generically as the internet protocol z Internet Protocol y One such internet protocol developed for ARPANET y RFC 791 (Get it and study it) z Lower layer protocol needed to access particular network

Connectionless Internetworking z Advantages y. Flexibility y. Robust y. No unnecessary overhead z Unreliable y. Not guaranteed delivery y. Not guaranteed order of delivery x. Packets can take different routes y. Reliability is responsibility of next layer up (e. g. TCP)

Internet protocol stack z application: supporting network applications y ftp, smtp, http z transport: host-host data transfer y tcp, udp z network: routing of datagrams from source to destination y ip, routing protocols z link: data transfer between neighboring network elements y ppp, ethernet z physical: bits “on the wire” application transport network link physical

Protocol layering and data Each layer takes data from above z adds header information to create new data unit z passes new data unit to layer below source M Ht M Hn Ht M Hl Hn Ht M application transport network link physical destination application Ht transport Hn Ht network Hl Hn Ht link physical M message M segment M datagram M frame

Internet Protocol (IP) z Only protocol at Layer 3 z Defines y Internet addressing y Internet packet format y Internet routing z RFC 791 (1981)

IP Address Details z 32 Bits - divided into two parts y Prefix identifies network y Suffix identifies host z Global authority assigns unique prefix to network (IANA) z Local administrator assigns unique suffix to host

IP Addresses given notion of “network”, let’s examine IP addresses: “class-full” addressing: class A 0 network B 10 C 110 D 1110 1. 0. 0. 0 to 127. 255 host network 128. 0. 0. 0 to 191. 255 host network multicast address 32 bits host 192. 0. 0. 0 to 223. 255 224. 0. 0. 0 to 239. 255

Classes and Network Sizes z Maximum network size determined by class of address y Class A large y Class B medium y Class C small

IP Addressing Example

Subnets and Subnet Masks z Allow arbitrary complexity of internetworked LANs within organization z Insulate overall internet from growth of network numbers and routing complexity z Site looks to rest of internet like single network z Each LAN assigned subnet number z Host portion of address partitioned into subnet number and host number z Local routers route within subnetted network z Subnet mask indicates which bits are subnet number and which are host number

Routing Using Subnets

IP addressing: CIDR z classful addressing: y inefficient use of address space, address space exhaustion y e. g. , class B net allocated enough addresses for 65 K hosts, even if only 2 K hosts in that network z CIDR: Classless Inter. Domain Routing y network portion of address of arbitrary length y address format: a. b. c. d/x, where x is # bits in network portion of address network part host part 11001000 00010111 00010000 200. 23. 16. 0/23

Internet Packets z z Contains sender and destination addresses Size depends on data being carried Called IP datagram Two Parts Of An IP Datagram z Header y Contains source and destination address y Fixed-size fields z Data Area (Payload) y Variable size up to 64 K y No minimum size

IP datagram format IP protocol version number header length (bytes) “type” of data max number remaining hops (decremented at each router) upper layer protocol to deliver payload to 32 bits ver head. type of len service length fragment 16 -bit identifier flgs offset time to upper Internet layer live checksum total datagram length (bytes) for fragmentation/ reassembly 32 bit source IP address 32 bit destination IP address Options (if any) data (variable length, typically a TCP or UDP segment) E. g. timestamp, record route taken, specify list of routers to visit.

IP Fragmentation & Reassembly z network links have MTU (max. transfer size) - largest possible link-level frame. fragmentation: in: one large datagram out: 3 smaller datagrams y different link types, different MTUs z large IP datagram divided (“fragmented”) within net y one datagram becomes several datagrams y “reassembled” only at final destination y IP header bits used to identify, order related fragments reassembly

IP Fragmentation and Reassembly length ID fragflag offset =4000 =x =0 =0 One large datagram becomes several smaller datagrams length ID fragflag offset =1500 =x =1 =0 length ID fragflag offset =1500 =x =1 =1480 length ID fragflag offset =1040 =x =0 =2960

IP Semantics z IP is connectionless y. Datagram contains identity of destination y. Each datagram sent/ handled independently z Routes can change at any time

IP Semantics (continued) z IP allows datagrams to be y. Delayed y. Duplicated y. Delivered out-of-order y. Lost z Called best effort delivery z Motivation: accommodate all possible networks

Datagram Lifetime z Datagrams could loop indefinitely y. Consumes resources y. Transport protocol may need upper bound on datagram life z Datagram marked with lifetime y. Time To Live field in IP y. Once lifetime expires, datagram discarded (not forwarded) y. Hop count x. Decrement time to live on passing through a each router y. Time count x. Need to know how long since last router

ICMP z Internet Control Message Protocol z RFC 792 z Transfer of (control) messages from routers and hosts to hosts z Feedback about problems ye. g. time to live expired z Encapsulated in IP datagram y. Not reliable

ICMP Error Messages z When an ICMP error message is sent, the message always contains the IP header and the first 8 bytes of the IP datagram that caused the problem z ICMP has rules regarding error message generation to prevent broadcast storms

ICMP Echo Command z Used by “ping” and “tracert” z When a destination IP host receives an ICMP echo command, it returns and ICMP “echo reply” z Ping uses this to determine if a path to a destination (and its return path) are “up” z Tracert uses echo in a clever way to determine the identities of the routers along the path (by “scoping” TTL).

Address Resolution Problem z Suppose we know the IP Address of a local system (one to which we are connected) z We would like to send an IP packet to that system. z The link layer (ethernet, for instance) only knows about MAC addresses! z How do we determine the MAC address associated with the IP address?

ARP z Address resolution provides a mapping between two different forms of addresses y 32 -bit IP addresses and whatever the data link uses z ARP (address resolution protocol) is a protocol used to do address resolution in the TCP/IP protocol suite (RFC 826) z ARP provides a dynamic mapping from an IP address to the corresponding hardware address

ARP Protocol z A knows B's IP address, wants to learn physical address of B z A broadcasts ARP query pkt, containing B's IP address y all machines on LAN receive ARP query z B receives ARP packet, replies to A with its (B's) physical layer address z A caches (saves) IP-to-physical address pairs until information becomes old (times out) y soft state: information that times out (goes away) unless refreshed

ARP Cache z The cache maintains the recent IP to physical address mappings z Each entry is aged (usually the lifetime is 20 minutes) forcing periodic updates of the cache z ARP replies are often broadcast so that all hosts can update their caches

ARP Packet Format 8 16 31 Hardware Type Hardware Size Protocol Type Protocol Size Operation Sender’s Hardware Address (for Ethernet 6 bytes) Sender’s Protocol Address (for IP 4 bytes) Target Hardware Address Target Protocol Address Destination IP Address

Internet Transport Protocols z Two Transport Protocols Available y Transmission Control Protocol (TCP) x connection oriented x most applications use TCP x. RFC 793 y User Datagram Protocol (UDP) x Connectionless x. RFC 768

Transport layer addressing z. Communications endpoint addressed by: y. IP address (32 bit) in IP Header y. Port number (16 bit) in TP Header 1 y. Transport protocol (TCP or UDP) in IP Header 1 TP => Transport Protocol (UDP or TCP)

Standard services and port numbers

TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581 z point-to-point: y one sender, one receiver z reliable, in-order byte steam: y no “message boundaries” z pipelined: y TCP congestion and flow control set window size z send & receive buffers z full duplex data: y bi-directional data flow in same connection y MSS: maximum segment size z connection-oriented: y handshaking (exchange of control msgs) init’s sender, receiver state before data exchange z flow controlled: y sender will not overwhelm receiver

TCP Header

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 UA P R S F len used checksum rcvr window size ptr urgent data Options (variable length) application data (variable length) counting by bytes of data (not segments!) # bytes rcvr willing to accept

Reliability in an Unreliable World z IP offers best-effort (unreliable) delivery z TCP uses IP z TCP provides completely reliable transfer z How is this possible? How can TCP realize: y Reliable connection startup? y Reliable data transmission? y Graceful connection shutdown?

Reliable Data Transmission z Positive acknowledgment y Receiver returns short message when data arrives y Called acknowledgment z Retransmission y Sender starts timer whenever message is transmitted y If timer expires before acknowledgment arrives, sender retransmits message y THIS IS NOT A TRIVIAL PROBLEM! – more on this later.

TCP Flow Control z Receiver y Advertises available buffer space y Called window y This is a known as a CREDIT policy z Sender y Can send up to entire window before ACK arrives z Each acknowledgment carries new window information y Called window advertisement y Can be zero (called closed window) z Interpretation: I have received up through X, and can take Y more octets

Credit Scheme z Decouples flow control from ACK y. May ACK without granting credit and vice versa z Each octet has sequence number z Each transport segment has seq number, ack number and window size in header

Use of Header Fields z When sending, seq number is that of first octet in segment z ACK includes AN=i, W=j z All octets through SN=i-1 acknowledged y. Next expected octet is i z Permission to send additional window of W=j octets yi. e. octets through i+j-1

Credit Allocation

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

TCP seq. #’s and ACKs Seq. #’s: y byte stream “number” of first byte in segment’s data ACKs: y seq # of next byte expected from other side y cumulative ACK Q: how receiver handles out-of-order segments y A: TCP spec doesn’t say, - up to implementor Host B Host A User types ‘C’ Seq=4 2, ACK = 79, da ta ta = 3, da 4 K= 9, AC eq=7 S host ACKs receipt of echoed ‘C’ = ‘C’ host ACKs receipt of ‘C’, echoes back ‘C’ Seq=4 3, ACK =80 simple telnet scenario time

TCP ACK generation [RFC 1122, RFC 2581] 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 arrival of segment that partially or completely fills gap immediate ACK if segment starts at lower end of gap

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

Why Startup/ Shutdown Difficult? z Segments can be y Lost y Duplicated y Delayed y Delivered out of order y Either side can crash y Either side can reboot z Need to avoid duplicate ‘‘shutdown’’ message from affecting later connection

TCP Connection Management Recall: TCP sender, receiver establish “connection” before exchanging data segments z initialize TCP variables: y seq. #s y buffers, flow control info (e. g. Rcv. Window) z client: connection initiator Socket client. Socket = new Socket("hostname", "port number"); z server: contacted by client Socket connection. Socket = welcome. Socket. accept(); Three way handshake: Step 1: client end system sends TCP SYN control segment to server y specifies initial seq # Step 2: server end system receives SYN, replies with SYNACK control segment y ACKs received SYN y allocates buffers y specifies server-> receiver initial seq. #

TCP Connection Management (OPEN) client opening server SYN ACK opening SYN ACK established closed

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

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

TCP Connection Management (cont) TCP server lifecycle TCP client lifecycle

Timing Problem! The delay required for data to reach a destination and an acknowledgment to return depends on traffic in the internet as well as the distance to the destination. Because it allows multiple application programs to communicate with multiple destinations concurrently, TCP must handle a variety of delays that can change rapidly. How does TCP handle this. . .

Solving Timing Problem z Keep estimate of round trip time on each connection z Use current estimate to set retransmission timer z Known as adaptive retransmission z Key to TCP’s success

TCP Round Trip Time and Timeout Q: how to set TCP timeout value? z longer than RTT y note: RTT will vary z too short: premature timeout y unnecessary retransmissions z too long: slow reaction to segment loss Q: how to estimate RTT? z Sample. RTT: measured time from segment transmission until ACK receipt y ignore retransmissions, cumulatively ACKed segments z Sample. RTT will vary, want estimated RTT “smoother” y use several recent measurements, not just current Sample. RTT

TCP Round Trip Time and Timeout Estimated. RTT = (1 -x)*Estimated. RTT + x*Sample. RTT z Exponential weighted moving average z influence of given sample decreases exponentially fast z typical value of x: 0. 1 Setting the timeout z Estimted. RTT plus “safety margin” z large variation in Estimated. RTT -> larger safety margin Timeout = Estimated. RTT + 4*Deviation = (1 -x)*Deviation + x*|Sample. RTT-Estimated. RTT|

Implementation Policy Options z Send z Deliver z Accept z Retransmit z Acknowledge

Send z If no push or close TCP entity transmits at its own convenience (IFF send window allows!) z Data buffered at transmit buffer z May construct segment per data batch z May wait for certain amount of data

Deliver (to application) z In absence of push, deliver data at own convenience z May deliver as each in-order segment received z May buffer data from more than one segment

Accept z Segments may arrive out of order z In order y. Only accept segments in order y. Discard out of order segments z In windows y. Accept all segments within receive window

Retransmit z TCP maintains queue of segments transmitted but not acknowledged z TCP will retransmit if not ACKed in given time y. First only y. Batch y. Individual

Acknowledgement z Immediate yas soon as segment arrives. ywill introduce extra network traffic y. Keeps sender’s pipe open z Cumulative y. Wait a bit before sending ACK (called “delayed ACK”) y. Must use timer to insure ACK is sent y. Less network traffic y. May let sender’s pipe fill if not timely!

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

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

UDP Uses z Inward data collection z Outward data dissemination z Request-Response z Real time application