Presentation is loading. Please wait.

Presentation is loading. Please wait.

Q1-1 Review for Quiz-1 ECE3600 - Fall 2015 Prof. John Copeland These slides include material from Computer Networking: A Top Down Approach Featuring the.

Similar presentations

Presentation on theme: "Q1-1 Review for Quiz-1 ECE3600 - Fall 2015 Prof. John Copeland These slides include material from Computer Networking: A Top Down Approach Featuring the."— Presentation transcript:

1 Q1-1 Review for Quiz-1 ECE Fall 2015 Prof. John Copeland These slides include material from Computer Networking: A Top Down Approach Featuring the Internet, 5th edition. Jim Kurose, Keith Ross Addison-Wesley. Base material copyright J.F Kurose and K.W. Ross, All Rights Reserved

2 Q1-2 What’s the Internet: “nuts and bolts” view protocols control sending, receiving of msgs –e.g., TCP, IP, HTTP, FTP, PPP Internet: “network of networks” –loosely hierarchical –public Internet versus private intranet Internet standards and assignments –RFC: Request for comments –IETF: Internet Engineering Task Force –IANA: assigns IP (32-bit) addresses –Registrars: assign domain names. local ISP company network regional ISP router workstation server mobile Chapter 1 - Introduction

3 Q1-3 Network edge: connectionless service Goal: data transfer between end systems –same as before! UDP - User Datagram Protocol [RFC 768]: –connectionless –unreliable data transfer –no flow control –no congestion control App’s using TCP: HTTP (Web), FTP (file transfer), Telnet (remote login), SMTP ( ) App’s using UDP: streaming media, teleconferencing, DNS, Internet telephony

4 Q1-4 Network Core: Circuit Switching End-end resources reserved for “call” link bandwidth, switch capacity dedicated resources: no sharing circuit-like (guaranteed) performance call setup required Used by telephone system. Expensive because unused channel capacity was wasted.

5 Q1-5 Packet Switching: Statistical Multiplexing Sequence of A & B packets does not have fixed pattern, shared on demand  statistical multiplexing. Contrast with TDM each host gets same slot in a repeating TDM frame. A B C 100 Mb/s Ethernet 1.5 Mb/s D E statistical multiplexing queue of packets waiting for output link

6 Q1-6 Company access: local area networks company/university local area network (LAN) connects end system to edge router Ethernet: –shared or dedicated link connects end system and router –10 Mbs, 100Mbps, Gigabit Ethernet LANs: chapter 5

7 Q1-7 Wireless access networks shared wireless access network connects end system to router –via base station aka “access point” wireless LANs: –802.11b/g (WiFi): 11 or 54 Mbps wider-area wireless access –provided by telco operator –3G ~ 384 kbps Will it happen?? –GPRS in Europe/US base station mobile hosts router

8 Q1-8 Physical Media Bit: propagates between transmitter/rcvr pairs physical link: what lies between transmitter & receiver guided media: –signals propagate in solid media: copper, fiber, coax unguided media: –signals propagate freely, e.g., radio Twisted Pair (TP) two insulated copper wires –Category 5: 100Mbps Ethernet Coaxial cable: two concentric copper conductors Fiber optic cable: glass fiber carrying light pulses, each pulse a bit 10’s-100’s Gbps

9 Q1-9 Internet structure: network of networks “Tier-3” ISPs and local ISPs –last hop (“access”) network (closest to end systems) Tier 1 ISP NAP Tier-2 ISP local ISP local ISP local ISP local ISP local ISP Tier 3 ISP local ISP local ISP local ISP Local and tier- 3 ISPs are customers of higher tier ISPs connecting them to rest of Internet Individual Users Large Organization (Autonomous System) Smaller Organization (Autonomous System)

10 Q1-10 How do loss and delay occur? packets queue in router buffers packet arrival rate to link exceeds output link capacity packets queue, wait for turn Delay = (bits ahead in buffer)/(bit-rate) A B packet being transmitted (delay) packets queueing (delay) free (available) buffers: arriving packets dropped (loss) if no free buffers

11 Q1-11 Four sources of packet delay 1. nodal processing: –check bit errors –determine output link A B propagation transmission nodal processing queueing 2. queueing –time waiting at output link for transmission –depends on congestion level of router

12 Q1-12 Delay in packet-switched networks 3. Transmission delay: R=link bandwidth (bps) L=packet length (bits) time to send bits into link = L/R 4. Propagation delay: d = length of physical link s = propagation speed in medium (~2x10 8 m/sec) propagation delay = d/s A B propagation transmission nodal processing queueing Note: s and R are very different quantities!

13 Q1-13 Nodal delay d proc = processing delay –typically a few microsecs or less d queue = queuing delay (bits-in-queue/rate) –depends on congestion d trans = transmission delay (bits-in-packet/rate) –= L/R, significant for low-speed links (dialup modems) d prop = propagation delay –a few microsecs to hundreds of msecs (15 ms to Los Angeles)

14 Q1-14 Internet protocol stack application: supporting network applications –FTP, SMTP, HTTP transport: process-process data transfer –TCP, UDP network: routing of datagrams from source to destination –IP, routing protocols link: data transfer between neighboring network elements –PPP, Ethernet physical: bits “on the wire” application transport network link physical LLC MAC Ethernet TCP/IP (voltage, photons, bits/s, media, …)

15 Q1-15 source application transport network link physical HtHt HnHn M segment HtHt datagram destination application transport network link physical HtHt HnHn HlHl M HtHt HnHn M HtHt M M network link physical link physical HtHt HnHn HlHl M HtHt HnHn M HtHt HnHn M HtHt HnHn HlHl M router switch Encapsulation message M HtHt M HnHn frame Ethernet LAN PPP SONET Fiber

16 Q1-16 Chapter 2 Applications, Application Layer, Application Layer Headers

17 Q1-17 Creating a network app Write programs that –run on different end systems and –communicate over a network. –e.g., Web: Web server software communicates with browser software little software written for devices in network core –network core devices do not run user application code –application on end systems allows for rapid app development, propagation application transport network data link physical application transport network data link physical application transport network data link physical

18 Q1-18 Client-server architecture server: –always-on host –permanent IP address –server farms for scaling clients: –communicate with server –may be intermittently connected –may have dynamic IP addresses –do not communicate directly with each other

19 Q1-19 Processes communicating Process: program running within a host. within same host, two processes communicate using inter-process communication (defined by OS). processes in different hosts communicate by exchanging messages Client process: process that initiates communication Server process: process that waits to be contacted Note: applications with P2P architectures have both client processes and server processes

20 Q1-20 Addressing processes to receive messages, process must have identifier host device has unique32-bit IP address Q: does IP address of host on which process runs suffice for identifying the process? –Answer: NO, many processes can be running on same host identifier includes both IP address and port numbers associated with process on host. Example port numbers: –HTTP server: 80 –Mail server: 25 to send HTTP message to web server: –IP address: –Port number: 80

21 Q1-21 HTTP overview HTTP: hypertext transfer protocol Web’s application layer protocol client/server model –client: browser that requests, receives, “displays” Web objects –server: Web server sends objects in response to requests HTTP 1.0: RFC 1945 HTTP 1.1: RFC 2068 PC running Explorer Server running Apache Web server Mac running Navigator HTTP request HTTP response Application Layer

22 Q1-22 Persistent HTTP Nonpersistent HTTP issues: requires 2 RTTs per object OS overhead for each TCP connection browsers often open parallel TCP connections to fetch referenced objects Persistent HTTP server leaves connection open after sending response subsequent HTTP messages between same client/server sent over open connection Persistent without pipelining: client issues new request only when previous response has been received one RTT for each referenced object Persistent with pipelining: default in HTTP/1.1 client sends requests as soon as it encounters a referenced object as little as one RTT for all the referenced objects [plus the sum of transfer times]

23 Q1-23 FTP: the file transfer protocol transfer file to/from remote host client/server model –client: side that initiates transfer (either to/from remote) –server: remote host ftp: RFC 959 ftp server: port 21 file transfer FTP server FTP user interface FTP client local file system remote file system user at host

24 Q1-24 FTP: separate control, data connections FTP client contacts FTP server at port 21, specifying TCP as transport protocol Client obtains authorization over control connection Client browses remote directory by sending commands over control connection. When server receives file transfer command, server opens 2 nd TCP connection (for file) to client After transferring one file, server closes data connection. FTP client FTP server TCP control connection port 21 TCP data connection 2 Modes Active : Server port 20 -> Client listening high port Passive : Client -> Server, high-high ports Server opens another TCP data connection to transfer another file. Control connection: “out of band” FTP server maintains “state”: current directory, earlier authentication

25 Q1-25 Electronic Mail: mail servers Mail Servers mailbox contains incoming messages for user message queue of outgoing (to be sent) mail messages SMTP protocol between mail servers to send messages –client: sending mail server –“server”: receiving mail server mail server user agent user agent user agent mail server user agent user agent mail server user agent SMTP Recently, Enhanced SMTP (ESMTP) is used to provide authentication, and encryption for privacy.

26 Q1-26 Mail message format SMTP: protocol for exchanging msgs RFC 822: standard for text message format: header lines, e.g., –To: –From: –Subject: different from SMTP commands! body –the “message”, ASCII characters only header body blank line

27 Q1-27 Mail access protocols SMTP: delivery/storage to receiver’s server Mail access protocol: retrieval from server –POP: Post Office Protocol [RFC 1939] authorization (agent server) and download –IMAP: Internet Mail Access Protocol [RFC 1730] more features (more complex) manipulation of stored msgs on server –HTTP: Hotmail, Yahoo! Mail, etc. Transport Layer Security (TLS), like SSL for HTTP > HTTPS] user agent sender ’ s mail server user agent SMTP access protocol receiver ’ s mail server

28 Q1-28 POP3 and IMAP More about POP3 Previous example uses “download and delete” mode. Bob cannot re-read e- mail if he changes client “Download-and-keep”: copies of messages on different clients POP3 is stateless across sessions IMAP Keep all messages in one place: the server Allows user to organize messages in folders IMAP keeps user state across sessions: –names of folders and mappings between message IDs and folder name

29 Q1-29 DNS: Domain Name System People: many identifiers: –SSN, name, passport # Internet hosts, routers: –IP address (32 bit) - used for addressing datagrams –“name”, e.g., - used by humans Q: map between IP addresses and name ? Domain Name System: distributed database implemented in hierarchy of many name servers application-layer protocol host, routers, name servers to communicate to resolve names (address/name translation) –note: core Internet function, implemented as application-layer protocol –complexity at network’s “edge”

30 Q1-30 Root DNS DNS DNS DNS servers DNS servers DNS servers DNS servers DNS servers DNS servers Distributed, Hierarchical Database Client wants IP for 1 st approx: Client* queries a root server to find com DNS server Client* queries com DNS server to get DNS server Client* queries DNS server to get IP address for –* This is usually your local DNS server, that does this "recursive" search for you.

31 Q1-31 TLD and Authoritative Servers Top-level domain (TLD) servers: responsible for com, org, net, edu, etc, and all top-level country domains uk, fr, ca, jp. –Network solutions maintains servers for com TLD –Educause for edu TLD –[ TLD servers share responsibilities] Authoritative DNS servers: organization’s DNS servers, providing authoritative hostname to IP mappings for organization’s servers (e.g., Web and mail). –Can be maintained by organization or service provider Local DNS servers: organization’s DNS servers located on various subnets to provide DNS lookups for hosts on the subnet. May not be accessible from outside the subnet. Their IP addresses are part of the host's network configuration (manual setup or DHCP*). * DHCP - dynamic host configuration protocol (automatic network configuration)

32 Q1-32 requesting host root DNS server local DNS server authoritative DNS server 7 8 TLD DNS server Example Host at wants IP address for Host sends a "recursion- requested" query request to [Host is doing a non- recursive search] Local DNS server does a "recursive" search. This requires contacting several other DNS servers before the final answer is given to host.

33 Q1-33 DNS records DNS: distributed db storing resource records (RR) Type=NS –name is domain (e.g. {assigned by a “registrar”} –value is hostname of authoritative name server for this domain RR format: (name, value, type, ttl) Type=A –name is hostname –value is IP address Type=CNAME –name is alias name for some “canonical” (the real) name is really –value is canonical name Type=MX –value is name of mailserver associated with name

34 Q1-34 P2P file sharing Example Alice runs P2P client application on her notebook computer Intermittently connects to Internet; gets new IP address for each connection Asks for “Hey Jude” Application displays other peers that have copy of Hey Jude. Alice chooses one of the peers, Bob. File is copied from Bob’s PC to Alice’s notebook: HTTP While Alice downloads, other users uploading from Alice. Alice’s peer is both a Web client and a transient Web server. All peers are servers = highly scalable! Highly insecure!

35 Q1-35 Internet transport protocols (2 of many) TCP services: connection-oriented: setup required between client and server processes reliable transport between sending and receiving process flow control: sender won’t overwhelm receiver congestion control: throttle sender when network overloaded does not provide: timing, minimum bandwidth guarantees UDP service: unreliable data transfer between sending and receiving process does not provide: connection setup, reliability, flow control, congestion control, timing, or bandwidth guarantee Q: why bother? Why is there a UDP? Transport Layer

36 Q1-36 Socket-programming using TCP Socket: a door between application process and end- end-transport protocol (UCP or TCP) TCP service: reliable transfer of bytes from one process to another process TCP with buffers, variables socket controlled by application developer controlled by operating system host or server process TCP with buffers, variables socket controlled by application developer controlled by operating system host or server internet

37 Q1-37 Socket programming with TCP Client must contact server server process must first be running server must have created socket that welcomes client’s contact (Listening Socket) Client contacts server by: creating client-local TCP socket specifying IP address, port number of server process When client creates socket: client TCP establishes connection to server TCP When contacted by client, server TCP creates new socket for server process to communicate with client –allows server to talk with multiple clients –source port numbers used to distinguish clients (more in Chap 3) TCP provides reliable, in-order transfer of bytes ( “ pipe ” ) between client and server application viewpoint

38 Q1-38 Chapter 3 - Transport Layer TCP and UDP, Ports and Sockets Covered on Quiz 2 (Fall 2014) TCP Flow and Congestion Control TCP Flags, Sequence and Ack. No.s IP Subnets, Routers, Address Blocks IP Subnets

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

40 Q1-40 Internet transport-layer protocols reliable, in-order delivery (TCP) –congestion control –flow control –connection setup unreliable, unordered delivery: UDP –no-frills extension of “best-effort” IP services not available: –delay guarantees –bandwidth guarantees application transport network data link physical application transport network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical logical end-end transport

41 Q1-41 TCP Multiplexing / Demultiplexing application transport network link physical P1 application transport network link physical application transport network link physical P2 P3 P4 P1 host 1 host 2 host 3 = process= socket delivering received segments to correct socket (Listening Port not shown) Demultiplexing at rcv host: gathering data from multiple sockets, enveloping data with header (later used for demultiplexing) Multiplexing at send host:

42 Q1-42 Connection-oriented demux TCP socket identified by 4-tuple: –source IP address –source port number –dest IP address –dest port number recv host uses all four values to direct segment to appropriate socket Server host may support many simultaneous TCP sockets: –each socket identified by its own 4-tuple Web servers have different sockets for each connecting client –non-persistent HTTP will have different socket for each request

43 Q1-43 UDP - Connectionless demux DatagramSocket serverSocket = new DatagramSocket(6428); Client IP:B P2 client IP: A P1 P3 server IP: C SP: 6428 DP: 9157 SP: 9157 DP: 6428 SP: 6428 DP: 5775 SP: 5775 DP: 6428 Source Port, SP, (and Source IP) provides “ return address ” Only one socket per local UDP Port Number.

44 Q1-44 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 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 Single thread and socket for each local server port number.

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

46 Q1-46 UDP checksum Sender: treat segment contents as sequence of 16-bit integers checksum: addition (1’s complement sum) of header and some parts of the IP header) sender puts bit-wise complement (-checksum) value into UDP checksum field Receiver: compute checksum of received segment, included checksum field. check if computed checksum equals zero : –NO - error detected –YES - no error detected. But maybe errors nonetheless? More later …. Goal: detect “errors” (e.g., flipped bits) in transmitted segment

47 Q1-47 Internet Checksum Example Note –When adding numbers, a carry out from the most significant bit needs to be shifted (>>16) and added to the result Example: add two 16-bit integers (1's compliment) wraparound sum bit-invert checksum BINARY ADD

48 Q1-48 Transport Layer Problem Packet may arrive with errors. Packet may not arrive. Sender may wait forever for ACK. ACK may not arrive, dup. sent. Packets may arrive out-of-order. Inefficient to send one pkt per RT Missing packet early in window. “Go-Back-N” inefficient Also in TCP --- Packets may be different sizes. Slow down when network congested (as detected by RTO or triple duplicate ACKs. Know when receiver buffer will be full. Solution Add checksum, CRC, or hash. Receiver sends “ACK” back. If ACK not received, packet re-sent. Timeout timer added to sender. Add sequence no.s to detect dups. Buffer packets to rearrange order. Have a “window” to send before ACK (pipelining). “Go-Back-N” to last in-order packet. “Selective Repeat” to fill in gaps only Sequence number for each byte. “Slow-Start”, or "Multiplicative Decrease" to reduce transmit window. Receiver includes “space left” in every ACK. Reliable Data Transport

49 Q1-49 TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581 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 controlled: –sender will not overwhelm receiver point-to-point: –one sender, one receiver reliable, in-order byte steam: –no “message boundaries” pipelined: –TCP congestion and flow control set window size send & receive buffers

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

51 Q1-51 TCP seq. #’s and ACKs Seq. #’s: –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 Host A Host B Seq=42, ACK=79, data = ‘C’ Seq=79, ACK=43, data = ‘C’ Seq=43, ACK=80 User types ‘ C ’ host ACKs receipt of echoed ‘ C ’ host ACKs receipt of ‘ C ’, echoes back ‘ C ’ time simple telnet scenario

52 Q1-52 Maximum Segment Size (MSS), in bytes The initial segments (the SYN and SYN-ACK) contain the MSS in an option field. It stays constant after this. This tells the other host the maximum size of a segment that can be handled by their local network (without fragmentation). Examples, one host may say it's MSS value is 1400, the other may say it's MSS value is Since segments have to transverse both local networks, the smaller MSS value is used for the connection. TCP rules involving Window sizes are in units of MSS (bytes), not number of segments. For simplification, examples may say "the host is sending maximum size segments," so that 1 MSS = 1 segment. Sometimes this is implied without being stated in problems. MSS includes the TCP header bytes (40 to 64) and data bytes, but not the IP header bytes (20). Since Ethernet and WiFi limit datagram size to 1500 bytes, MSS is never larger than 1480 bytes when either host is on a LAN.

53 Q1-53 TCP Round Trip Time and Timeout EstimatedRTT [new] = (1-  )* EstimatedRTT [old] +  * SampleRTT [new] Exponential weighted moving average influence of past sample decreases exponentially fast typical value:  = Setting the timeout  EstimtedRTT plus “ safety margin ”  large variation in EstimatedRTT -> larger safety margin r first estimate how much SampleRTT deviates from EstimatedRTT: DevRTT [new] = (1-  ) * DevRTT [old] +  * | SampleRTT [new] - EstimatedRTT [old] | (typically,  = 0.25, note absolute value bars, ||) TimeoutInterval: RTO = EstimatedRTT + 4 * DevRTT Also note: Old value of EstimatedRTT is used.

54 Q1-54 A = * * 90 = > 64 D = 0.75 * * | 30 | = 15 A = * * 30 = > 60 D = 0.75 * * | -34 | = > 20 Running Average for Calculating the Retransmit Time Out, RTO Round results up to 1 ms. Alpha = 1/8 (0.125) and Beta = 1/4 (0.250) 124 SampleRTT EstimatedRTT DevRTT TimeOut SampleRTT[new] - EstimatedRTT[old ] -34

55 Q1-55 sender won ’ t overflow receiver ’ s buffer by transmitting too much, too fast flow control TCP Flow control Receiver-Window = spare room in buffer = LastByteInBuffer - LastByteACKed Receiver advertises spare room by including value of RcvWindow in every segment (TCP header "Window" field) Sender limits data to RcvWindow –guarantees receive buffer doesn’t overflow LastByte InBuffer LastByte ACKed <- Byte No.s

56 Q1-56 Causes / costs of congestion Each host sends in data ( average bits per second ). Buffer output is out (maximum rate is C) two senders, two receivers one router, infinite buffers no retransmission large delays when congested maximum achievable throughput unlimited shared output link buffers Host A in : original data Host B out

57 Q1-57 TCP Congestion Control sender limits transmission: LastByteSent-LastByteAcked  CongWin Roughly*, CongWin is dynamic, function of perceived network congestion. The sender uses the smaller value of CongWin and or Window (receiver's Window) How does sender perceive congestion? loss event = timeout or 3 duplicate ACKs TCP sender reduces rate ( CongWin ) after loss event three mechanisms: –AIMD (additive increase, multiplicative decrease) –slow start initially (exponential growth until threshold reached) –conservative after timeout events (slow- start up to CongWin) rate = CongWin RTT Bytes/sec * This is true when this window-limited rate is less that the media bandwidth in bytes per second.

58 Q1-58 TCP Slow Start When connection begins*, increase rate exponentially until first loss event: –double CongWin every RTT –done by adding a byte to CongWin for every new byte ACK'ed. Summary: initial rate is slow but data rate ramps up exponentially fast (until the Receiver Window is reached) Host A one (MSS) segment RTT Host B time two segments four segments *Also done after a Time Out, but changes to Additive Increase when the Threshold is reached. SYN and SYN-ACK: TCP headers contain MSS values (in option field) and initial Segment Numbers.

59 Q1-59 TCP congestion control: sender congestion window: "CongWin" Approach: increase transmission rate (window size), probing for usable bandwidth, until loss occurs –multiplicative decrease: cut CongWin in half after loss indicated by 3 duplicate ACKs (to MSS after Time Out*). –additive increase: increase CongWin by 1 MSS every RTT until loss detected by 3 duplicate ACKs (or Time Out*) time congestion window size Saw tooth behavior: probing for bandwidth *After a Time Out, CongWin increases by doubling every RTT until 1/2 old CongWin reached

60 Q1-60 Refinement Q: When should the exponential increase switch to linear (after RTO)? A: When CongWin gets to 1/2 of its value before timeout. Implementation: Variable Threshold At loss event, Threshold is set to 1/2 of CongWin value just before loss event. Fast Recovery (3 dups) (Fast Retransmission replaced missing segment) Time-Out (dt>RTO) If a Fast Retransmit fixes the gap in ACKs before a timeout, TCP can skip the Slow-Start and immediately use Additive Increase, starting at half the previous CongWin. CongWin (MSS) (Time/RTT) Time-Out (CongWin = 16) TCP Reno

61 Q1-61 Fast Retransmit (to avoid Timeout) Time-out period often relatively long: –long delay before resending lost packet Detect lost segments via duplicate ACKs. –Sender often sends many segments back-to-back –If segment is lost, there will likely be many duplicate ACKs. If sender receives 4 ACKs for the same data (3 dups), it supposes that segment after ACKed data was lost: –Fast Retransmit: resend segment before timer expires. When resent packet is ACKed before a timeout, go to Fast Recovery Mode: - Halve Sender-Window, "CongWin" - Increase CongWin by 1 MSS per CongWin bytes sent and Acked.

62 Q1-62 CongWin / mss Threshold = 20 Time Out 3 Dup. ACKs 12 6 CongWin <= Threshold: Doubles each RTT (add MSS for each ACK) CongWin > Threshold: Adds MSS each RTT Time Out: Threshold = 1/2 CongWin, CongWin = 1 (Slow-Start) 3-Dup Ack: Threshold = 1/2 CongWin, CongWin = Threshold (Fast Recovery)

63 Q1-63 Fairness 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 Research area: make UDP more TCP friendly –Solution: reserve 50% of router buffer space for TCP segments (excess UDP segments dropped). 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 starts 1 TCP, gets rate R/10 –new app starts 9 TCPs, gets R/2 !

Download ppt "Q1-1 Review for Quiz-1 ECE3600 - Fall 2015 Prof. John Copeland These slides include material from Computer Networking: A Top Down Approach Featuring the."

Similar presentations

Ads by Google