presentationphysicallyer.pdf talked about computer networks
- 1. ECE534/634 Communication Networks CSC424 Computer Networks Transport Layer Application Layer 1
- 2. Previously … • How TCP implements AIMD – ACK clock – Slow-start – Fast-retransmit – Fast-recovery 2
- 4. Fast Retransmission/Recovery • How TCP implements AIMD, part 2 –“Fast retransmit” and “fast recovery” are the MD portion of AIMD 4 AIMD sawtooth
- 5. Inferring Loss from ACKs • TCP uses a cumulative ACK – Carries highest in-order seq. number – Normally a steady advance • Duplicate ACKs give us hints about what data hasn’t arrived – Tell us some new data did arrive, but it was not next segment – Thus the next segment may be lost 5
- 6. Fast Retransmit • Treat three duplicate ACKs as a loss – Retransmit next expected segment – Some repetition allows for reordering, but still detects loss quickly 6 Ack 1 2 3 4 5 5 5 5 5 5 Resend 6
- 7. Fast Retransmit 7 Ack 10 Ack 11 Ack 12 Ack 13 . . . Ack 13 Ack 13 Ack 13 Data 14 . . . Ack 13 Ack 20 . . . . . . Data 20 Third duplicate ACK, so send 14 Retransmission fills in the hole at 14 ACK jumps after loss is repaired . . . . . . Data 14 was lost earlier, but got 15 to 20
- 8. Fast Retransmit • It can repair single segment loss quickly, typically before a timeout • However, we have quiet time at the sender/receiver while waiting for the ACK to jump • And we still need to MD cwnd … 8
- 9. Inferring Non-Loss from ACKs • Duplicate ACKs also give us hints about what data has arrived –Each new duplicate ACK means that some new segment has arrived –It will be the segments after the loss –Thus advancing the sliding window will not increase the number of segments stored in the network 9
- 10. Fast Recovery • First fast retransmit, and MD cwnd • Then pretend further duplicate ACKs are the expected ACKs – Lets new segments be sent for ACKs – Reconcile views when the ACK jumps 10 Ack 1 2 3 4 5 5 5 5 5 5 Resend 6 Send new data 12
- 11. Fast Recovery 11 Ack 12 Ack 13 Ack 13 Ack 13 Ack 13 Data 14 Ack 13 Ack 20 . . . . . . Data 20 Third duplicate ACK, so send 14 Data 14 was lost earlier, but got 15 to 20 Retransmission fills in the hole at 14 Set ssthresh, cwnd = cwnd/2 Data 21 Data 22 More ACKs advance window; may send segments before jump Ack 13 Exit Fast Recovery
- 12. Fast Recovery • With fast retransmit, it repairs a single segment loss quickly and keeps the ACK clock running • This allows us to realize AIMD – No timeouts or slow-start after loss, just continue with a smaller cwnd • TCP Reno combines slow-start, fast retransmit and fast recovery – Multiplicative Decrease is ½ 12
- 13. TCP Reno 13 MD of ½ , no slow-start ACK clock running TCP sawtooth
- 14. Example 14
- 15. TCP Reno, NewReno, and SACK • Reno can repair one loss per RTT – Multiple losses cause a timeout • NewReno further refines ACK heuristics – Repairs multiple losses without timeout • SACK is a better idea – Receiver sends ACK ranges so sender can retransmit without guesswork 15
- 16. Congestion Avoidance vs. Control • Classic TCP drives the network into congestion and then recovers – Needs to see loss to slow down • Would be better to use the network but avoid congestion altogether! – Reduces loss and delay • But how can we do this? 16
- 17. Feedback Signals • Delay and router signals can let us avoid congestion 17 Signal Example Protocol Pros / Cons Packet loss Classic TCP Cubic TCP (Linux) Hard to get wrong Hear about congestion late Packet delay Compound TCP (Windows) Hear about congestion early Need to infer congestion Router indication TCPs with Explicit Congestion Notification Hear about congestion early Require router support
- 18. ECN (Explicit Congestion Notification) • Router detects the onset of congestion via its queue – When congested, it marks affected packets (IP header) 18
- 19. ECN (Explicit Congestion Notification) • Marked packets arrive at receiver; treated as loss – TCP receiver reliably informs TCP sender of the congestion 19
- 20. ECN (Explicit Congestion Notification) • Advantages: –Routers deliver clear signal to hosts –Congestion is detected early, no loss –No extra packets need to be sent • Disadvantages: –Routers and hosts must be upgraded 20
- 21. Where we are in the Course • Application Layer! – Builds distributed “network services” (DNS, Web) on Transport services 21 Physical Link Application Network Transport
- 22. Recall • Application layer protocols are often part of an “app” – But don’t need a GUI, e.g., DNS 22 TCP IP 802.11 HTTP app OS User-level (NIC)
- 23. Recall • Application layer messages are often split over multiple packets – Or may be aggregated in a packet … 23 802.11 IP TCP HTTP 802.11 IP TCP HTTP 802.11 IP TCP HTTP HTTP
- 24. Application Needs from Transport • Data integrity – 100% reliable data transfer – tolerate some loss • Throughput – some apps (e.g., multimedia) require minimum amount of throughput to be “effective” – “elastic apps” • Timing – some apps (e.g., Internet telephony, interactive games) require low delay to be “effective” • Security – encryption, data integrity, … 24
- 25. Recall 25 • TCP – reliable transport – flow control – congestion control – does not provide: timing, minimum throughput guarantee, security • UDP – unreliable data transfer – does not provide: reliability, flow control, congestion control, timing, throughput guarantee, security, or connection setup.
- 26. Application Communication Needs • Vary widely with app; must build on Transport services 26 UDP DNS TCP Series of variable length, reliable request/reply exchanges Web UDP Real-time (unreliable) stream delivery Skype Short, reliable request/reply exchanges Message reliability!
- 27. Evolution of Internet Applications • Always changing, and growing … 27 2010 1970 1990 1980 2000 Traffic File Transfer (FTP) Email (SMTP) News (NTTP) Secure Shell (ssh) Telnet Email Web (HTTP) Web (CDNs) P2P (BitTorrent) Web (Video) ???
- 28. Evolution of the Web 28 Source: http://www.evolutionoftheweb.com, Vizzuality, Google, and Hyperakt
- 29. Evolution of the Web 29 Source: http://www.evolutionoftheweb.com, Vizzuality, Google, and Hyperakt
- 30. Web 1.0, Web 2.0, and Web 3.0 30 Web 1.0 Web 2.0 Web 3.0 Time 1989-2005 1999-2012 2006-ongoing Content Typically read-only Strongly read-write Read-write-interact Functiona lities No user-to-server communication Content browsing only Online documents, Video streaming, Cloud computing operations Edge computing, Blockchain, Artificial intelligence, Example MySpace and LiveJournal Facebook Apple’s Siri
- 31. Web 31 • An web page consists of objects (i.e., HTML file, JPEG image, audio file) – Each object is stored on different Web servers • An web page consists of base HTML-file which includes several referenced objects, each addressable by a URL, e.g., https://www.google.com/images/branding/googlelogo/2x/googlelogo_color_272x92dp.png host name path name
- 32. HTTP 32 • Hypertext transfer protocol (HTTP) – Web’s application layer protocol – client/server model
- 33. HTTP Properties 33 • HTTP uses TCP • HTTP is “stateless” – Server cannot maintain past client requests • Two types of connections – Non-persistent – Persistent
- 34. Non-persistent HTTP 34 • TCP connection opened • At most one object sent over TCP connection • TCP connection closed • Repeat until all objects are transmitted
- 35. Non-persistent HTTP 35 Client Server TCP connection ACK Time Time Sequence Diagram object request one object three-way handshake close connection TCP connection
- 36. Non-persistent HTTP 36 • Response time – One RTT to initiate TCP connection – One RTT for HTTP request and first few bytes of HTTP response to return – Object transmission time
- 37. Response time 37 Client Server TCP connection ACK Time object request one object RTT RTT
- 38. Persistent HTTP 38 Client Server TCP connection ACK Time Time Sequence Diagram object 1 request object 1 object 2 request