Presentation is loading. Please wait.

Presentation is loading. Please wait.

ECE Fall 2015 Prof. John Copeland

Similar presentations


Presentation on theme: "ECE Fall 2015 Prof. John Copeland"— Presentation transcript:

1 ECE3600 - Fall 2015 Prof. John Copeland
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 Chapter 1 - Introduction
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. router workstation server mobile local ISP regional ISP company network

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 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 Packet Switching: Statistical Multiplexing
100 Mb/s Ethernet C A statistical multiplexing 1.5 Mb/s B queue of packets waiting for output link D E 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.

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

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) packet being transmitted (delay) A free (available) buffers: arriving packets dropped (loss) if no free buffers packets queueing (delay) B

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

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 (~2x108 m/sec) propagation delay = d/s Note: s and R are very different quantities! A B propagation transmission nodal processing queueing

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

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 TCP/IP LLC MAC Ethernet (voltage, photons, bits/s, media, …)

15 Encapsulation source Ethernet LAN PPP destination SONET Fiber
message M application transport network link physical segment Ht M Ht datagram Ht Hn M Hn frame Ht Hn Hl M link physical Ethernet LAN switch PPP destination network link physical Ht Hn M application transport network link physical Ht Hn Hl M M Ht Hn M Ht M Ht Hn M router Ht Hn Hl M SONET Fiber

16 Chapter 2 Applications, Application Layer, Application Layer Headers

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

18 Client-server architecture
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 Processes communicating
Client process: process that initiates communication Server process: process that waits to be contacted 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 Note: applications with P2P architectures have both client processes and server processes

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 gaia.cs.umass.edu web server: IP address: Port number: 80

21 Application Layer 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 HTTP request PC running Explorer HTTP response HTTP request Server running Apache Web server HTTP response Mac running Navigator

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 FTP: the file transfer protocol
user interface client file transfer FTP server remote file system user at host local file system 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

24 FTP: separate control, data connections
client 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 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 2nd TCP connection (for file) to client After transferring one file, server closes data connection. Server opens another TCP data connection to transfer another file. Control connection: “out of band” FTP server maintains “state”: current directory, earlier authentication

25 Electronic Mail: mail servers
user agent 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 SMTP mail server user agent SMTP mail server SMTP user agent user agent Recently, Enhanced SMTP (ESMTP) is used to provide authentication, and encryption for privacy. user agent

26 Mail message format SMTP: protocol for exchanging email 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 blank line body

27 Mail access protocols SMTP SMTP access protocol
user agent user agent sender’s mail server receiver’s mail server 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]

28 POP3 and IMAP More about POP3 IMAP
Previous example uses “download and delete” mode. Bob cannot re-read 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 DNS: 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” 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 ?

30 Distributed, Hierarchical Database
Root DNS Servers .com DNS servers .org DNS servers .edu DNS servers poly.edu DNS servers umass.edu yahoo.com amazon.com pbs.org Client wants IP for 1st approx: Client* queries a root server to find com DNS server Client* queries com DNS server to get amazon.com DNS server Client* queries amazon.com DNS server to get IP address for * This is usually your local DNS server, that does this "recursive" search for you.

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 authoritative DNS server
Example root DNS server Host at cis.poly.edu wants IP address for gaia.cs.umass.edu Host sends a "recursion-requested" query request to dns.poly.edu. [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. 2 3 TLD DNS server 4 5 local DNS server dns.poly.edu 7 6 1 8 authoritative DNS server dns.cs.umass.edu requesting host cis.poly.edu gaia.cs.umass.edu

33 RR format: (name, value, type, ttl)
DNS records DNS: distributed db storing resource records (RR) 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 servereast.backup2.ibm.com value is canonical name Type=NS name is domain (e.g. gatech.com) {assigned by a “registrar”} value is hostname of authoritative name server for this domain Type=MX value is name of mailserver associated with name

34 P2P file sharing Alice chooses one of the peers, Bob. Example
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! 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.

35 Internet transport protocols (2 of many)
Transport Layer 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?

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 controlled by application developer controlled by application developer process TCP with buffers, variables socket process TCP with buffers, variables socket controlled by operating system controlled by operating system internet host or server host or server

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 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 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 network data link physical network data link physical network data link physical logical end-end transport network data link physical network data link physical application transport network data link physical

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 network data link physical network data link physical network data link physical logical end-end transport network data link physical network data link physical application transport network data link physical

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

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 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 DP: 5775 SP: 5775 Source Port, SP, (and Source IP) provides “return address” Only one socket per local UDP Port Number.

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 UDP: more other UDP uses 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! 32 bits source port # dest port # Length, in bytes of UDP segment, including header length checksum Application data (message) UDP segment format

46 UDP checksum Goal: detect “errors” (e.g., flipped bits) in transmitted segment 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 …. 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

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) 1 BINARY ADD wraparound sum bit-invert checksum

48 Reliable Data Transport
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. Transport Layer

49 TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581 point-to-point:
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 TCP segment structure source port # dest port # application data
counting by bytes of data (not segments!) source port # dest port # 32 bits application data (variable length) sequence number acknowledgement number Receive window Urg data pointer checksum F S R P A U head len not used Options (variable length, MSS) URG: urgent data (generally not used) ACK: ACK # valid PSH: push data now (end of block) # bytes rcvr willing to accept RST, SYN, FIN: connection estab (setup, teardown commands) Internet checksum (as in UDP)

51 simple telnet scenario
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 User types ‘C’ Seq=42, ACK=79, data = ‘C’ host ACKs receipt of ‘C’, echoes back ‘C’ Seq=79, ACK=43, data = ‘C’ host ACKs receipt of echoed ‘C’ Seq=43, ACK=80 time simple telnet scenario

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 1420. 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 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:  = 0.125 Setting the timeout EstimtedRTT plus “safety margin” large variation in EstimatedRTT -> larger safety margin first estimate how much SampleRTT deviates from EstimatedRTT: DevRTT[new] = (1-) * DevRTT[old] +  * |SampleRTT[new] - EstimatedRTT[old]| (typically,  = 0.25, note absolute value bars, ||) Also note: Old value of EstimatedRTT is used. TimeoutInterval: RTO = EstimatedRTT + 4 * DevRTT

54 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) SampleRTT[new] - EstimatedRTT[old] SampleRTT EstimatedRTT DevRTT TimeOut 124 -34 A = * * 90 = > 64 D = 0.75 * * | 30 | = 15 A = * * 30 = > 60 D = 0.75 * * | -34 | = > 20

55 TCP Flow control Receiver-Window = spare room in buffer
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 Receiver-Window = spare room in buffer = LastByteInBuffer LastByteACKed sender won’t overflow receiver’s buffer by transmitting too much, too fast flow control

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

57 TCP Congestion Control
How does sender perceive congestion? loss event = timeout or 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) 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) rate = CongWin RTT Bytes/sec * This is true when this window-limited rate is less that the media bandwidth in bytes per second.

58 TCP Slow Start SYN and SYN-ACK: TCP headers contain MSS values (in option field) and initial Segment Numbers. 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 Host B one (MSS) segment RTT two segments four segments time *Also done after a Time Out, but changes to Additive Increase when the Threshold is reached.

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*) Saw tooth behavior: probing for bandwidth congestion window size time *After a Time Out, CongWin increases by doubling every RTT until 1/2 old CongWin reached

60 replaced missing segment)
Refinement Q: When should the exponential increase switch to linear (after RTO)? A: When CongWin gets to 1/2 of its value before timeout. Fast Recovery (3 dups) (Fast Retransmission replaced missing segment) Time-Out (CongWin = 16) TCP Reno CongWin (MSS) Time-Out (dt>RTO) Implementation: Variable Threshold At loss event, Threshold is set to 1/2 of CongWin value just before loss event. (Time/RTT) 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.

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 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) CongWin / mss Time Out Threshold = 20 3 Dup. ACKs 12 6

63 Fairness 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 ! 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).


Download ppt "ECE Fall 2015 Prof. John Copeland"

Similar presentations


Ads by Google