Your SlideShare is downloading. ×
0
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
20080426 networking carzaniga_lecture01-02
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

20080426 networking carzaniga_lecture01-02

1,149

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,149
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
10
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Computer Networks: The Transport Layer Antonio Carzaniga Faculty of Informatics University of Lugano St. Petersburg, Russia April 26, 2008 c 2005–2008 Antonio Carzaniga
  • 2. Outline Very quick intro to computer networking The transport layer ◮ reliability ◮ congestion control ◮ brief intro to TCP c 2005–2008 Antonio Carzaniga
  • 3. Application web web browser server c 2005–2008 Antonio Carzaniga
  • 4. Application web web browser server c 2005–2008 Antonio Carzaniga
  • 5. Application GET /carzaniga/ HTTP/1.1 Host: www.inf.unisi.ch ... web web browser server c 2005–2008 Antonio Carzaniga
  • 6. Application web web browser server HTTP/1.1 200 OK ... <html><head>. . . </head><body> ... c 2005–2008 Antonio Carzaniga
  • 7. Application GET /carzaniga/anto.png HTTP/1.1 Host: www.inf.unisi.ch ... web web browser server c 2005–2008 Antonio Carzaniga
  • 8. Application web web browser server HTTP/1.1 200 OK ... ... c 2005–2008 Antonio Carzaniga
  • 9. Transport web web browser server c 2005–2008 Antonio Carzaniga
  • 10. Transport web web browser server c 2005–2008 Antonio Carzaniga
  • 11. Transport web web browser server c 2005–2008 Antonio Carzaniga
  • 12. Network web web browser server c 2005–2008 Antonio Carzaniga
  • 13. Network web web browser server c 2005–2008 Antonio Carzaniga
  • 14. Network web web browser server c 2005–2008 Antonio Carzaniga
  • 15. Network c 2005–2008 Antonio Carzaniga
  • 16. Network c 2005–2008 Antonio Carzaniga
  • 17. Network c 2005–2008 Antonio Carzaniga
  • 18. Network c 2005–2008 Antonio Carzaniga
  • 19. Network c 2005–2008 Antonio Carzaniga
  • 20. Network c 2005–2008 Antonio Carzaniga
  • 21. Network c 2005–2008 Antonio Carzaniga
  • 22. Network Potentially multiple paths for the same source/destination c 2005–2008 Antonio Carzaniga
  • 23. Network Potentially multiple paths for the same source/destination c 2005–2008 Antonio Carzaniga
  • 24. Network Potentially multiple paths for the same source/destination c 2005–2008 Antonio Carzaniga
  • 25. Network Potentially multiple paths for the same source/destination c 2005–2008 Antonio Carzaniga
  • 26. Network Potentially multiple paths for the same source/destination c 2005–2008 Antonio Carzaniga
  • 27. Network Potentially multiple paths for the same source/destination c 2005–2008 Antonio Carzaniga
  • 28. Network Potentially multiple paths for the same source/destination c 2005–2008 Antonio Carzaniga
  • 29. Network Potentially multiple paths for the same source/destination c 2005–2008 Antonio Carzaniga
  • 30. Network Potentially multiple paths for the same source/destination Potentially asymmetric paths c 2005–2008 Antonio Carzaniga
  • 31. Network Potentially multiple paths for the same source/destination Potentially asymmetric paths c 2005–2008 Antonio Carzaniga
  • 32. Network Potentially multiple paths for the same source/destination Potentially asymmetric paths c 2005–2008 Antonio Carzaniga
  • 33. Network Potentially multiple paths for the same source/destination Potentially asymmetric paths c 2005–2008 Antonio Carzaniga
  • 34. Network Potentially multiple paths for the same source/destination Potentially asymmetric paths c 2005–2008 Antonio Carzaniga
  • 35. Network Potentially multiple paths for the same source/destination Potentially asymmetric paths c 2005–2008 Antonio Carzaniga
  • 36. A “Datagram” Network c 2005–2008 Antonio Carzaniga
  • 37. A “Datagram” Network Packet-switched network c 2005–2008 Antonio Carzaniga
  • 38. A “Datagram” Network Packet-switched network ◮ information is transmitted in discrete units called datagrams c 2005–2008 Antonio Carzaniga
  • 39. A “Datagram” Network Packet-switched network ◮ information is transmitted in discrete units called datagrams Connectionless service c 2005–2008 Antonio Carzaniga
  • 40. A “Datagram” Network Packet-switched network ◮ information is transmitted in discrete units called datagrams Connectionless service ◮ a datagram is a self-contained message ◮ treated independently by the network ◮ no connection setup/tear-down phase c 2005–2008 Antonio Carzaniga
  • 41. A “Datagram” Network Packet-switched network ◮ information is transmitted in discrete units called datagrams Connectionless service ◮ a datagram is a self-contained message ◮ treated independently by the network ◮ no connection setup/tear-down phase “Best-effort” service c 2005–2008 Antonio Carzaniga
  • 42. A “Datagram” Network Packet-switched network ◮ information is transmitted in discrete units called datagrams Connectionless service ◮ a datagram is a self-contained message ◮ treated independently by the network ◮ no connection setup/tear-down phase “Best-effort” service ◮ delivery guarantee: none c 2005–2008 Antonio Carzaniga
  • 43. A “Datagram” Network Packet-switched network ◮ information is transmitted in discrete units called datagrams Connectionless service ◮ a datagram is a self-contained message ◮ treated independently by the network ◮ no connection setup/tear-down phase “Best-effort” service ◮ delivery guarantee: none ◮ maximum latency guarantee: none c 2005–2008 Antonio Carzaniga
  • 44. A “Datagram” Network Packet-switched network ◮ information is transmitted in discrete units called datagrams Connectionless service ◮ a datagram is a self-contained message ◮ treated independently by the network ◮ no connection setup/tear-down phase “Best-effort” service ◮ delivery guarantee: none ◮ maximum latency guarantee: none ◮ bandwidth guarantee: none c 2005–2008 Antonio Carzaniga
  • 45. A “Datagram” Network Packet-switched network ◮ information is transmitted in discrete units called datagrams Connectionless service ◮ a datagram is a self-contained message ◮ treated independently by the network ◮ no connection setup/tear-down phase “Best-effort” service ◮ delivery guarantee: none ◮ maximum latency guarantee: none ◮ bandwidth guarantee: none ◮ in-order delivery guarantee: none c 2005–2008 Antonio Carzaniga
  • 46. A “Datagram” Network Packet-switched network ◮ information is transmitted in discrete units called datagrams Connectionless service ◮ a datagram is a self-contained message ◮ treated independently by the network ◮ no connection setup/tear-down phase “Best-effort” service ◮ delivery guarantee: none ◮ maximum latency guarantee: none ◮ bandwidth guarantee: none ◮ in-order delivery guarantee: none ◮ congestion indication: none c 2005–2008 Antonio Carzaniga
  • 47. Transport-Layer Value-Added Service c 2005–2008 Antonio Carzaniga
  • 48. Transport-Layer Value-Added Service Transport-layer multiplexing/demultiplexing ◮ i.e., connecting applications as opposed to hosts c 2005–2008 Antonio Carzaniga
  • 49. Transport-Layer Value-Added Service Transport-layer multiplexing/demultiplexing ◮ i.e., connecting applications as opposed to hosts Reliable data transfer ◮ i.e., integrity and possibly ordered delivery c 2005–2008 Antonio Carzaniga
  • 50. Transport-Layer Value-Added Service Transport-layer multiplexing/demultiplexing ◮ i.e., connecting applications as opposed to hosts Reliable data transfer ◮ i.e., integrity and possibly ordered delivery Connections ◮ i.e., streams ◮ can be seen as the same as ordered dalivery c 2005–2008 Antonio Carzaniga
  • 51. Transport-Layer Value-Added Service Transport-layer multiplexing/demultiplexing ◮ i.e., connecting applications as opposed to hosts Reliable data transfer ◮ i.e., integrity and possibly ordered delivery Connections ◮ i.e., streams ◮ can be seen as the same as ordered dalivery Congestion control ◮ i.e., end-to-end traffic (admission) control so as to avoid destructive congestions within the network c 2005–2008 Antonio Carzaniga
  • 52. Transport web web browser server c 2005–2008 Antonio Carzaniga
  • 53. Transport web web browser server c 2005–2008 Antonio Carzaniga
  • 54. Transport web web browser server c 2005–2008 Antonio Carzaniga
  • 55. Transport web web browser server unreliable, datagram =⇒ reliable “stream” c 2005–2008 Antonio Carzaniga
  • 56. Part I Reliable Streams on Unreliable Networks c 2005–2008 Antonio Carzaniga
  • 57. Finite-State Machines c 2005–2008 Antonio Carzaniga
  • 58. Finite-State Machines A finite-state machine (FSM) is a mathematical abstraction ◮ a.k.a., finite-state automaton (FSA), deterministic finite-state automaton (DFA), non-deterministic finite-state automaton (NFA) c 2005–2008 Antonio Carzaniga
  • 59. Finite-State Machines A finite-state machine (FSM) is a mathematical abstraction ◮ a.k.a., finite-state automaton (FSA), deterministic finite-state automaton (DFA), non-deterministic finite-state automaton (NFA) Very useful to specify and implement network protocols c 2005–2008 Antonio Carzaniga
  • 60. Finite-State Machines A finite-state machine (FSM) is a mathematical abstraction ◮ a.k.a., finite-state automaton (FSA), deterministic finite-state automaton (DFA), non-deterministic finite-state automaton (NFA) Very useful to specify and implement network protocols Ubiquitous in computer science ◮ theory of formal languages ◮ compiler design ◮ theory of computation ◮ text processing ◮ behavior specification ◮ ... c 2005–2008 Antonio Carzaniga
  • 61. Finite-State Machines x S1 S2 x c 2005–2008 Antonio Carzaniga
  • 62. Finite-State Machines x S1 S2 x States are represented as nodes in a graph c 2005–2008 Antonio Carzaniga
  • 63. Finite-State Machines x S1 S2 x States are represented as nodes in a graph Transitions are represented as directed edges in the graph c 2005–2008 Antonio Carzaniga
  • 64. Finite-State Machines x S1 S2 x States are represented as nodes in a graph Transitions are represented as directed edges in the graph ◮ an edge labeled x going from state S1 to state S2 says that when the machine is in state S1 and event x occurs, the machine switches to state S2 c 2005–2008 Antonio Carzaniga
  • 65. Finite-State Machines x S1 S2 x States are represented as nodes in a graph Transitions are represented as directed edges in the graph ◮ an edge labeled x going from state S1 to state S2 says that when the machine is in state S1 and event x occurs, the machine switches to state S2 button-pushed On Off button-pushed c 2005–2008 Antonio Carzaniga
  • 66. Finite-State Machines reset set 1 0 reset set c 2005–2008 Antonio Carzaniga
  • 67. Finite-State Machines reset set 1 0 reset set try-unlock button-1 button-2 1s timeout locked unlocked 30s timeout c 2005–2008 Antonio Carzaniga
  • 68. Finite-State Machines a game A 40/0 a b a 30/0 40/15 a a a b a b adv. A 15/0 30/15 40/30 b a b a b a b a 0/0 15/15 30/30 deuce b a b a b a b 0/15 15/30 30/40 a b a b a adv. B b b 0/30 15/40 b a b 0/40 game B b c 2005–2008 Antonio Carzaniga
  • 69. FSMs to Specify Protocols c 2005–2008 Antonio Carzaniga
  • 70. FSMs to Specify Protocols States represent the state of a protocol c 2005–2008 Antonio Carzaniga
  • 71. FSMs to Specify Protocols States represent the state of a protocol Transitions are characterized by an event/action label ◮ event: typically consists of an input message or a timeout ◮ action: typically consists of an output message c 2005–2008 Antonio Carzaniga
  • 72. FSMs to Specify Protocols States represent the state of a protocol Transitions are characterized by an event/action label ◮ event: typically consists of an input message or a timeout ◮ action: typically consists of an output message E.g., here’s a specification of a “simple conversation protocol” “Hello!” input “Yo” output S C “bla” “aha” “Bye.” “Okay. Bye.” 30s “Gotta go. Bye.” c 2005–2008 Antonio Carzaniga
  • 73. Example E.g., a subset of a server-side, SMTP-like protocol 30sec close R 60s close “RCPT TO” accept “MAIL FROM” “DATA” “250 Ok” “220 Ok” “250 Ok” “354 end with .” S A D M line 60sec “MAIL FROM” “RCPT TO” close “250 Ok” “250 Ok” “.” “250 accepted” “QUIT” T “221 bye”,close 30sec close c 2005–2008 Antonio Carzaniga
  • 74. Back to Reliable Data Transfer application Web Web browser server c 2005–2008 Antonio Carzaniga
  • 75. Back to Reliable Data Transfer application Web Web browser server network best-effort (i.e., unreliable) network c 2005–2008 Antonio Carzaniga
  • 76. Back to Reliable Data Transfer application Web Web browser server transport reliable-transfer reliable-transfer protocol protocol network best-effort (i.e., unreliable) network c 2005–2008 Antonio Carzaniga
  • 77. Back to Reliable Data Transfer application Web Web browser server r_send() r_recv() transport reliable-transfer reliable-transfer protocol protocol network best-effort (i.e., unreliable) network c 2005–2008 Antonio Carzaniga
  • 78. Back to Reliable Data Transfer application Web Web browser server r_send() r_recv() transport reliable-transfer reliable-transfer protocol protocol u_send() u_recv() network best-effort (i.e., unreliable) network c 2005–2008 Antonio Carzaniga
  • 79. Back to Reliable Data Transfer application Web Web browser server r_send() r_recv() r_send() r_recv() transport reliable-transfer reliable-transfer protocol protocol u_send() u_recv() u_send() u_recv() network best-effort (i.e., unreliable) network c 2005–2008 Antonio Carzaniga
  • 80. Reliable Data Transfer Model sender receiver c 2005–2008 Antonio Carzaniga
  • 81. Reliable Data Transfer Model sender receiver reliable-transfer protocol (sender) c 2005–2008 Antonio Carzaniga
  • 82. Reliable Data Transfer Model sender receiver r_send() reliable-transfer protocol (sender) c 2005–2008 Antonio Carzaniga
  • 83. Reliable Data Transfer Model sender receiver r_send() reliable-transfer protocol (sender) u_send() u_recv() network c 2005–2008 Antonio Carzaniga
  • 84. Reliable Data Transfer Model sender receiver r_send() r_recv() reliable-transfer reliable-transfer protocol protocol (sender) (receiver) u_send() u_recv() u_send() u_recv() network c 2005–2008 Antonio Carzaniga
  • 85. Baseline Protocol Reliable transport protocol that uses a reliable network (obviously a contrived example) sender r send(data) S u send(data) c 2005–2008 Antonio Carzaniga
  • 86. Baseline Protocol Reliable transport protocol that uses a reliable network (obviously a contrived example) sender receiver r send(data) u recv(data) S R u send(data) r recv(data) c 2005–2008 Antonio Carzaniga
  • 87. Baseline Protocol Reliable transport protocol that uses a reliable network (obviously a contrived example) sender receiver r send(data) u recv(data) S R u send(data) r recv(data) c 2005–2008 Antonio Carzaniga
  • 88. Noisy Channel c 2005–2008 Antonio Carzaniga
  • 89. Noisy Channel Reliable transport protocol over a network with bit errors ◮ every so often, a bit will be modified during transmission ◮ that is, a bit will be “flipped” ◮ however, no packets will be lost c 2005–2008 Antonio Carzaniga
  • 90. Noisy Channel Reliable transport protocol over a network with bit errors ◮ every so often, a bit will be modified during transmission ◮ that is, a bit will be “flipped” ◮ however, no packets will be lost How do people deal with such situations? (Think of a phone call over a noisy line) c 2005–2008 Antonio Carzaniga
  • 91. Noisy Channel Reliable transport protocol over a network with bit errors ◮ every so often, a bit will be modified during transmission ◮ that is, a bit will be “flipped” ◮ however, no packets will be lost How do people deal with such situations? (Think of a phone call over a noisy line) ◮ error detection: the receiver must be able to know when a received packet is corrupted (i.e., when it contains flipped bits) c 2005–2008 Antonio Carzaniga
  • 92. Noisy Channel Reliable transport protocol over a network with bit errors ◮ every so often, a bit will be modified during transmission ◮ that is, a bit will be “flipped” ◮ however, no packets will be lost How do people deal with such situations? (Think of a phone call over a noisy line) ◮ error detection: the receiver must be able to know when a received packet is corrupted (i.e., when it contains flipped bits) ◮ receiver feedback: the receiver must be able to alert the sender that a corrupted packet was received c 2005–2008 Antonio Carzaniga
  • 93. Noisy Channel Reliable transport protocol over a network with bit errors ◮ every so often, a bit will be modified during transmission ◮ that is, a bit will be “flipped” ◮ however, no packets will be lost How do people deal with such situations? (Think of a phone call over a noisy line) ◮ error detection: the receiver must be able to know when a received packet is corrupted (i.e., when it contains flipped bits) ◮ receiver feedback: the receiver must be able to alert the sender that a corrupted packet was received ◮ retransmission: the sender retransmits corrupted packets c 2005–2008 Antonio Carzaniga
  • 94. Error Detection c 2005–2008 Antonio Carzaniga
  • 95. Error Detection Key idea: sending redundant information ◮ e.g., the sender could repeat the message twice c 2005–2008 Antonio Carzaniga
  • 96. Error Detection Key idea: sending redundant information ◮ e.g., the sender could repeat the message twice ◮ error iff the receiver hears two different messages c 2005–2008 Antonio Carzaniga
  • 97. Error Detection Key idea: sending redundant information ◮ e.g., the sender could repeat the message twice ◮ error iff the receiver hears two different messages ◮ not very efficient: uses twice the number of bits c 2005–2008 Antonio Carzaniga
  • 98. Error Detection Key idea: sending redundant information ◮ e.g., the sender could repeat the message twice ◮ error iff the receiver hears two different messages ◮ not very efficient: uses twice the number of bits Error-detection codes c 2005–2008 Antonio Carzaniga
  • 99. Error Detection Key idea: sending redundant information ◮ e.g., the sender could repeat the message twice ◮ error iff the receiver hears two different messages ◮ not very efficient: uses twice the number of bits Error-detection codes ◮ e.g., the parity bit c 2005–2008 Antonio Carzaniga
  • 100. Error Detection Key idea: sending redundant information ◮ e.g., the sender could repeat the message twice ◮ error iff the receiver hears two different messages ◮ not very efficient: uses twice the number of bits Error-detection codes ◮ e.g., the parity bit ◮ sender adds one bit that is the xor of all the bits in the message c 2005–2008 Antonio Carzaniga
  • 101. Error Detection Key idea: sending redundant information ◮ e.g., the sender could repeat the message twice ◮ error iff the receiver hears two different messages ◮ not very efficient: uses twice the number of bits Error-detection codes ◮ e.g., the parity bit ◮ sender adds one bit that is the xor of all the bits in the message ◮ receiver computes the xor of all the bits and concludes that there was an error if the result is not 0 (i.e., if it is 1) c 2005–2008 Antonio Carzaniga
  • 102. Error Detection Key idea: sending redundant information ◮ e.g., the sender could repeat the message twice ◮ error iff the receiver hears two different messages ◮ not very efficient: uses twice the number of bits Error-detection codes ◮ e.g., the parity bit ◮ sender adds one bit that is the xor of all the bits in the message ◮ receiver computes the xor of all the bits and concludes that there was an error if the result is not 0 (i.e., if it is 1) Sender: message is 1001011011101000 c 2005–2008 Antonio Carzaniga
  • 103. Error Detection Key idea: sending redundant information ◮ e.g., the sender could repeat the message twice ◮ error iff the receiver hears two different messages ◮ not very efficient: uses twice the number of bits Error-detection codes ◮ e.g., the parity bit ◮ sender adds one bit that is the xor of all the bits in the message ◮ receiver computes the xor of all the bits and concludes that there was an error if the result is not 0 (i.e., if it is 1) Sender: message is 1001011011101000 ⇒ send 10010110111010000 c 2005–2008 Antonio Carzaniga
  • 104. Error Detection Key idea: sending redundant information ◮ e.g., the sender could repeat the message twice ◮ error iff the receiver hears two different messages ◮ not very efficient: uses twice the number of bits Error-detection codes ◮ e.g., the parity bit ◮ sender adds one bit that is the xor of all the bits in the message ◮ receiver computes the xor of all the bits and concludes that there was an error if the result is not 0 (i.e., if it is 1) Sender: message is 1001011011101000 ⇒ send 10010110111010000 c 2005–2008 Antonio Carzaniga
  • 105. Error Detection Key idea: sending redundant information ◮ e.g., the sender could repeat the message twice ◮ error iff the receiver hears two different messages ◮ not very efficient: uses twice the number of bits Error-detection codes ◮ e.g., the parity bit ◮ sender adds one bit that is the xor of all the bits in the message ◮ receiver computes the xor of all the bits and concludes that there was an error if the result is not 0 (i.e., if it is 1) Sender: message is 1001011011101000 ⇒ send 10010110111010000 Receiver: receives 10010110101010000 c 2005–2008 Antonio Carzaniga
  • 106. Error Detection Key idea: sending redundant information ◮ e.g., the sender could repeat the message twice ◮ error iff the receiver hears two different messages ◮ not very efficient: uses twice the number of bits Error-detection codes ◮ e.g., the parity bit ◮ sender adds one bit that is the xor of all the bits in the message ◮ receiver computes the xor of all the bits and concludes that there was an error if the result is not 0 (i.e., if it is 1) Sender: message is 1001011011101000 ⇒ send 10010110111010000 Receiver: receives 10010110101010000 ⇒ error! c 2005–2008 Antonio Carzaniga
  • 107. Noisy Channel Sender ◮ [data]∗ indicates a packet containing data plus an error-detection code (i.e., a checksum) c 2005–2008 Antonio Carzaniga
  • 108. Noisy Channel Sender ◮ [data]∗ indicates a packet containing data plus an error-detection code (i.e., a checksum) r send(data) data pkt = [data]∗ u send(data pkt) u recv(pkt) S ACK and pkt is NACK u send(data pkt) u recv(pkt) and pkt is ACK c 2005–2008 Antonio Carzaniga
  • 109. Noisy Channel Sender ◮ [data]∗ indicates a packet containing data plus an error-detection code (i.e., a checksum) r send(data) data pkt = [data]∗ u send(data pkt) u recv(pkt) S ACK and pkt is NACK u send(data pkt) u recv(pkt) and pkt is ACK Receiver u recv(pkt) u recv(pkt) and pkt is good R and pkt is corrupted u send(ACK) u send(NACK) r recv(pkt) c 2005–2008 Antonio Carzaniga
  • 110. Noisy Channel c 2005–2008 Antonio Carzaniga
  • 111. Noisy Channel This protocol is “synchronous” or “stop-and-wait” for each packet ◮ i.e., the sender must receive a (positive) acknowledgment before it can take more data from the application layer c 2005–2008 Antonio Carzaniga
  • 112. Noisy Channel This protocol is “synchronous” or “stop-and-wait” for each packet ◮ i.e., the sender must receive a (positive) acknowledgment before it can take more data from the application layer Does the protocol really work? c 2005–2008 Antonio Carzaniga
  • 113. Noisy Channel This protocol is “synchronous” or “stop-and-wait” for each packet ◮ i.e., the sender must receive a (positive) acknowledgment before it can take more data from the application layer Does the protocol really work? What happens if an error occurs within an ACK/NACK packet? c 2005–2008 Antonio Carzaniga
  • 114. Dealing With Bad ACKs/NACKs c 2005–2008 Antonio Carzaniga
  • 115. Dealing With Bad ACKs/NACKs Negative acknowledgments for ACKs and NACKs 1. sender says: “let’s go see Taxi Driver” 2. receiver hears: “let’s . . . Taxi . . . ” c 2005–2008 Antonio Carzaniga
  • 116. Dealing With Bad ACKs/NACKs Negative acknowledgments for ACKs and NACKs 1. sender says: “let’s go see Taxi Driver” 2. receiver hears: “let’s . . . Taxi . . . ” 3. receiver says: “Repeat message!” c 2005–2008 Antonio Carzaniga
  • 117. Dealing With Bad ACKs/NACKs Negative acknowledgments for ACKs and NACKs 1. sender says: “let’s go see Taxi Driver” 2. receiver hears: “let’s . . . Taxi . . . ” 3. receiver says: “Repeat message!” 4. sender hears: “. . . noise . . . ” c 2005–2008 Antonio Carzaniga
  • 118. Dealing With Bad ACKs/NACKs Negative acknowledgments for ACKs and NACKs 1. sender says: “let’s go see Taxi Driver” 2. receiver hears: “let’s . . . Taxi . . . ” 3. receiver says: “Repeat message!” 4. sender hears: “. . . noise . . . ” 5. sender says: “Repeat your ACK please!” 6. ... c 2005–2008 Antonio Carzaniga
  • 119. Dealing With Bad ACKs/NACKs Negative acknowledgments for ACKs and NACKs 1. sender says: “let’s go see Taxi Driver” 2. receiver hears: “let’s . . . Taxi . . . ” 3. receiver says: “Repeat message!” 4. sender hears: “. . . noise . . . ” 5. sender says: “Repeat your ACK please!” 6. ... Not Good: this protocol doesn’t seem to end c 2005–2008 Antonio Carzaniga
  • 120. Dealing With Bad ACKs/NACKs Negative acknowledgments for ACKs and NACKs 1. sender says: “let’s go see Taxi Driver” 2. receiver hears: “let’s . . . Taxi . . . ” 3. receiver says: “Repeat message!” 4. sender hears: “. . . noise . . . ” 5. sender says: “Repeat your ACK please!” 6. ... Not Good: this protocol doesn’t seem to end Make ACK/NACK packets so redundant that the sender can always figure out what the message is, even if a few bits are corrupted c 2005–2008 Antonio Carzaniga
  • 121. Dealing With Bad ACKs/NACKs Negative acknowledgments for ACKs and NACKs 1. sender says: “let’s go see Taxi Driver” 2. receiver hears: “let’s . . . Taxi . . . ” 3. receiver says: “Repeat message!” 4. sender hears: “. . . noise . . . ” 5. sender says: “Repeat your ACK please!” 6. ... Not Good: this protocol doesn’t seem to end Make ACK/NACK packets so redundant that the sender can always figure out what the message is, even if a few bits are corrupted ◮ good enough for channels that do not loose messages c 2005–2008 Antonio Carzaniga
  • 122. Dealing With Bad ACKs/NACKs Negative acknowledgments for ACKs and NACKs 1. sender says: “let’s go see Taxi Driver” 2. receiver hears: “let’s . . . Taxi . . . ” 3. receiver says: “Repeat message!” 4. sender hears: “. . . noise . . . ” 5. sender says: “Repeat your ACK please!” 6. ... Not Good: this protocol doesn’t seem to end Make ACK/NACK packets so redundant that the sender can always figure out what the message is, even if a few bits are corrupted ◮ good enough for channels that do not loose messages Assume a NACK and simply retransmit the packet c 2005–2008 Antonio Carzaniga
  • 123. Dealing With Bad ACKs/NACKs Negative acknowledgments for ACKs and NACKs 1. sender says: “let’s go see Taxi Driver” 2. receiver hears: “let’s . . . Taxi . . . ” 3. receiver says: “Repeat message!” 4. sender hears: “. . . noise . . . ” 5. sender says: “Repeat your ACK please!” 6. ... Not Good: this protocol doesn’t seem to end Make ACK/NACK packets so redundant that the sender can always figure out what the message is, even if a few bits are corrupted ◮ good enough for channels that do not loose messages Assume a NACK and simply retransmit the packet ◮ good idea, but it introduces duplicate packets (why?) c 2005–2008 Antonio Carzaniga
  • 124. Dealing With Duplicate Packets c 2005–2008 Antonio Carzaniga
  • 125. Dealing With Duplicate Packets The sender adds a sequence number to each packet so that the receiver can determine whether a packet is a retransmission 1. sender says: “7: let’s go see Taxi Driver” c 2005–2008 Antonio Carzaniga
  • 126. Dealing With Duplicate Packets The sender adds a sequence number to each packet so that the receiver can determine whether a packet is a retransmission 1. sender says: “7: let’s go see Taxi Driver” 2. receiver hears: “7: let’s go see Taxi Driver” 3. receiver passes “let’s go see Taxi Driver” to application layer 4. receiver says: “Got it!” (i.e., ACK) c 2005–2008 Antonio Carzaniga
  • 127. Dealing With Duplicate Packets The sender adds a sequence number to each packet so that the receiver can determine whether a packet is a retransmission 1. sender says: “7: let’s go see Taxi Driver” 2. receiver hears: “7: let’s go see Taxi Driver” 3. receiver passes “let’s go see Taxi Driver” to application layer 4. receiver says: “Got it!” (i.e., ACK) 5. sender hears: “. . . noise . . . ” c 2005–2008 Antonio Carzaniga
  • 128. Dealing With Duplicate Packets The sender adds a sequence number to each packet so that the receiver can determine whether a packet is a retransmission 1. sender says: “7: let’s go see Taxi Driver” 2. receiver hears: “7: let’s go see Taxi Driver” 3. receiver passes “let’s go see Taxi Driver” to application layer 4. receiver says: “Got it!” (i.e., ACK) 5. sender hears: “. . . noise . . . ” 6. sender (assuming a NACK) says: “7: let’s go see Taxi Driver” c 2005–2008 Antonio Carzaniga
  • 129. Dealing With Duplicate Packets The sender adds a sequence number to each packet so that the receiver can determine whether a packet is a retransmission 1. sender says: “7: let’s go see Taxi Driver” 2. receiver hears: “7: let’s go see Taxi Driver” 3. receiver passes “let’s go see Taxi Driver” to application layer 4. receiver says: “Got it!” (i.e., ACK) 5. sender hears: “. . . noise . . . ” 6. sender (assuming a NACK) says: “7: let’s go see Taxi Driver” 7. receiver hears: “7: let’s go see Taxi Driver” 8. receiver ignores the packet c 2005–2008 Antonio Carzaniga
  • 130. Dealing With Duplicate Packets The sender adds a sequence number to each packet so that the receiver can determine whether a packet is a retransmission 1. sender says: “7: let’s go see Taxi Driver” 2. receiver hears: “7: let’s go see Taxi Driver” 3. receiver passes “let’s go see Taxi Driver” to application layer 4. receiver says: “Got it!” (i.e., ACK) 5. sender hears: “. . . noise . . . ” 6. sender (assuming a NACK) says: “7: let’s go see Taxi Driver” 7. receiver hears: “7: let’s go see Taxi Driver” 8. receiver ignores the packet How many bits do we need for the sequence number? c 2005–2008 Antonio Carzaniga
  • 131. Dealing With Duplicate Packets The sender adds a sequence number to each packet so that the receiver can determine whether a packet is a retransmission 1. sender says: “7: let’s go see Taxi Driver” 2. receiver hears: “7: let’s go see Taxi Driver” 3. receiver passes “let’s go see Taxi Driver” to application layer 4. receiver says: “Got it!” (i.e., ACK) 5. sender hears: “. . . noise . . . ” 6. sender (assuming a NACK) says: “7: let’s go see Taxi Driver” 7. receiver hears: “7: let’s go see Taxi Driver” 8. receiver ignores the packet How many bits do we need for the sequence number? ◮ this is a “stop-and-wait” protocol for each packet, so the receiver needs to distinguish between (1) the next packet and (2) the retransmission of the current packet c 2005–2008 Antonio Carzaniga
  • 132. Dealing With Duplicate Packets The sender adds a sequence number to each packet so that the receiver can determine whether a packet is a retransmission 1. sender says: “7: let’s go see Taxi Driver” 2. receiver hears: “7: let’s go see Taxi Driver” 3. receiver passes “let’s go see Taxi Driver” to application layer 4. receiver says: “Got it!” (i.e., ACK) 5. sender hears: “. . . noise . . . ” 6. sender (assuming a NACK) says: “7: let’s go see Taxi Driver” 7. receiver hears: “7: let’s go see Taxi Driver” 8. receiver ignores the packet How many bits do we need for the sequence number? ◮ this is a “stop-and-wait” protocol for each packet, so the receiver needs to distinguish between (1) the next packet and (2) the retransmission of the current packet ◮ so, one bit is sufficient c 2005–2008 Antonio Carzaniga
  • 133. Using Sequence Numbers: Sender r send(data) data pkt = [0, data]∗ u send(data pkt) u recv(pkt) and (pkt is NACK S0 ACK0 or pkt is corrupted) u send(data pkt) u recv(pkt) and pkt is good and pkt is ACK u recv(pkt) and pkt is good and pkt is ACK u recv(pkt) and (pkt is NACK or pkt is corrupted) ACK1 S1 u send(data pkt) r send(data) data pkt = [1, data]∗ u send(data pkt) c 2005–2008 Antonio Carzaniga
  • 134. Using Sequence Numbers: Receiver u recv(pkt) u recv(pkt) and pkt is good R0 and pkt is corrupted and seq num(pkt) is 1 u send([NACK]∗ ) u send([ACK]∗ ) u recv(pkt) u recv(pkt) and pkt is good and pkt is good and seq num(pkt) is 1 and seq num(pkt) is 0 u send([ACK]∗ ) u send([ACK]∗ ) r recv(pkt) r recv(pkt) u recv(pkt) u recv(pkt) and pkt is good R1 and pkt is corrupted and seq num(pkt) is 0 u send([NACK]∗ ) u send([ACK]∗ ) c 2005–2008 Antonio Carzaniga
  • 135. Better Use of ACKs Do we really need both ACKs and NACKs? c 2005–2008 Antonio Carzaniga
  • 136. Better Use of ACKs Do we really need both ACKs and NACKs? Idea: now that we have sequence numbers, the receiver can convey the semantics of a NACK by sending an ACK for the last good packet it received c 2005–2008 Antonio Carzaniga
  • 137. Better Use of ACKs Do we really need both ACKs and NACKs? Idea: now that we have sequence numbers, the receiver can convey the semantics of a NACK by sending an ACK for the last good packet it received 1. sender says: “7: let’s go see Taxi Driver” 2. receiver hears: “7: let’s go see Taxi Driver” 3. receiver says: “Got it!” 4. sender hears: “Got it!” 5. sender says: “8: let’s meet at 8:00PM” 6. receiver hears: “. . . noise . . . ” c 2005–2008 Antonio Carzaniga
  • 138. Better Use of ACKs Do we really need both ACKs and NACKs? Idea: now that we have sequence numbers, the receiver can convey the semantics of a NACK by sending an ACK for the last good packet it received 1. sender says: “7: let’s go see Taxi Driver” 2. receiver hears: “7: let’s go see Taxi Driver” 3. receiver says: “Got it!” 4. sender hears: “Got it!” 5. sender says: “8: let’s meet at 8:00PM” 6. receiver hears: “. . . noise . . . ” 7. receiver now says: “Got 7” (instead of saying “Please, resend”) 8. sender hears: “Got 7” c 2005–2008 Antonio Carzaniga
  • 139. Better Use of ACKs Do we really need both ACKs and NACKs? Idea: now that we have sequence numbers, the receiver can convey the semantics of a NACK by sending an ACK for the last good packet it received 1. sender says: “7: let’s go see Taxi Driver” 2. receiver hears: “7: let’s go see Taxi Driver” 3. receiver says: “Got it!” 4. sender hears: “Got it!” 5. sender says: “8: let’s meet at 8:00PM” 6. receiver hears: “. . . noise . . . ” 7. receiver now says: “Got 7” (instead of saying “Please, resend”) 8. sender hears: “Got 7” 9. sender knows that the current message is 8, and therefore repeats: “8: let’s meet at 8:00PM” c 2005–2008 Antonio Carzaniga
  • 140. ACK-Only Protocol: Sender S0 c 2005–2008 Antonio Carzaniga
  • 141. ACK-Only Protocol: Sender r send(data) data pkt = [0, data]∗ u send(data pkt) S0 ACK0 c 2005–2008 Antonio Carzaniga
  • 142. ACK-Only Protocol: Sender r send(data) data pkt = [0, data]∗ u send(data pkt) S0 ACK0 u recv(pkt) and pkt is good and pkt = (ACK, 0) S1 c 2005–2008 Antonio Carzaniga
  • 143. ACK-Only Protocol: Sender r send(data) data pkt = [0, data]∗ u send(data pkt) S0 ACK0 u recv(pkt) and pkt is good and pkt = (ACK, 0) ACK1 S1 r send(data) data pkt = [1, data]∗ u send(data pkt) c 2005–2008 Antonio Carzaniga
  • 144. ACK-Only Protocol: Sender r send(data) data pkt = [0, data]∗ u send(data pkt) S0 ACK0 u recv(pkt) and pkt is good and pkt = (ACK, 1) u recv(pkt) and pkt is good and pkt = (ACK, 0) ACK1 S1 r send(data) data pkt = [1, data]∗ u send(data pkt) c 2005–2008 Antonio Carzaniga
  • 145. ACK-Only Protocol: Sender r send(data) data pkt = [0, data]∗ u send(data pkt) u recv(pkt) and (pkt = (ACK, 1) S0 ACK0 or pkt is corrupted) u send(data pkt) u recv(pkt) and pkt is good and pkt = (ACK, 1) u recv(pkt) and pkt is good and pkt = (ACK, 0) ACK1 S1 r send(data) data pkt = [1, data]∗ u send(data pkt) c 2005–2008 Antonio Carzaniga
  • 146. ACK-Only Protocol: Sender r send(data) data pkt = [0, data]∗ u send(data pkt) u recv(pkt) and (pkt = (ACK, 1) S0 ACK0 or pkt is corrupted) u send(data pkt) u recv(pkt) and pkt is good and pkt = (ACK, 1) u recv(pkt) and pkt is good and pkt = (ACK, 0) u recv(pkt) and (pkt = (ACK, 0) or pkt is corrupted) ACK1 S1 u send(data pkt) r send(data) data pkt = [1, data]∗ u send(data pkt) c 2005–2008 Antonio Carzaniga
  • 147. ACK-Only Protocol: Receiver R0 c 2005–2008 Antonio Carzaniga
  • 148. ACK-Only Protocol: Receiver R0 u recv(pkt) and pkt is good and seq num(pkt) is 0 u send([ACK,0]∗) r recv(pkt) R1 c 2005–2008 Antonio Carzaniga
  • 149. ACK-Only Protocol: Receiver R0 u recv(pkt) u recv(pkt) and pkt is good and pkt is good and seq num(pkt) is 1 and seq num(pkt) is 0 u send([ACK,1]∗) u send([ACK,0]∗) r recv(pkt) r recv(pkt) R1 c 2005–2008 Antonio Carzaniga
  • 150. ACK-Only Protocol: Receiver u recv(pkt) R0 and pkt is corrupted u send([ACK,1]∗) u recv(pkt) u recv(pkt) and pkt is good and pkt is good and seq num(pkt) is 1 and seq num(pkt) is 0 u send([ACK,1]∗) u send([ACK,0]∗) r recv(pkt) r recv(pkt) u recv(pkt) R1 and pkt is corrupted u send([ACK,0]∗) c 2005–2008 Antonio Carzaniga
  • 151. ACK-Only Protocol: Receiver u recv(pkt) u recv(pkt) and pkt is good R0 and pkt is corrupted and seq num(pkt) is 1 u send([ACK,1]∗) u send([ACK,1]∗) u recv(pkt) u recv(pkt) and pkt is good and pkt is good and seq num(pkt) is 1 and seq num(pkt) is 0 u send([ACK,1]∗) u send([ACK,0]∗) r recv(pkt) r recv(pkt) u recv(pkt) u recv(pkt) and pkt is good R1 and pkt is corrupted and seq num(pkt) is 0 u send([ACK,0]∗) u send([ACK,0]∗) c 2005–2008 Antonio Carzaniga
  • 152. Summary of Principles and Techniques c 2005–2008 Antonio Carzaniga
  • 153. Summary of Principles and Techniques Error detection codes (checksums) can be used to detect transmission errors c 2005–2008 Antonio Carzaniga
  • 154. Summary of Principles and Techniques Error detection codes (checksums) can be used to detect transmission errors Retransmission allows us to recover from transmission errors c 2005–2008 Antonio Carzaniga
  • 155. Summary of Principles and Techniques Error detection codes (checksums) can be used to detect transmission errors Retransmission allows us to recover from transmission errors ACKs and NACKs give feedback to the sender ◮ ACKs and NACKs are also “protected” with an error-detection code c 2005–2008 Antonio Carzaniga
  • 156. Summary of Principles and Techniques Error detection codes (checksums) can be used to detect transmission errors Retransmission allows us to recover from transmission errors ACKs and NACKs give feedback to the sender ◮ ACKs and NACKs are also “protected” with an error-detection code ◮ corrupted ACKs are interpreded as NACKs, possibly generating duplicate segments c 2005–2008 Antonio Carzaniga
  • 157. Summary of Principles and Techniques Error detection codes (checksums) can be used to detect transmission errors Retransmission allows us to recover from transmission errors ACKs and NACKs give feedback to the sender ◮ ACKs and NACKs are also “protected” with an error-detection code ◮ corrupted ACKs are interpreded as NACKs, possibly generating duplicate segments Sequence numbers allow the receiver to ignore duplicate data segments c 2005–2008 Antonio Carzaniga
  • 158. Lossy And Noisy Channel c 2005–2008 Antonio Carzaniga
  • 159. Lossy And Noisy Channel Reliable transport protocol over a network that may ◮ introduce bit errors ◮ loose packets c 2005–2008 Antonio Carzaniga
  • 160. Lossy And Noisy Channel Reliable transport protocol over a network that may ◮ introduce bit errors ◮ loose packets How do people deal with such situations? (Think of radio transmissions over a noisy and shared medium. Also, think about what we just did for noisy channels) c 2005–2008 Antonio Carzaniga
  • 161. Lossy And Noisy Channel Reliable transport protocol over a network that may ◮ introduce bit errors ◮ loose packets How do people deal with such situations? (Think of radio transmissions over a noisy and shared medium. Also, think about what we just did for noisy channels) Detection: the receiver and/or the sender must be able to determine that a packet was lost (how?) c 2005–2008 Antonio Carzaniga
  • 162. Lossy And Noisy Channel Reliable transport protocol over a network that may ◮ introduce bit errors ◮ loose packets How do people deal with such situations? (Think of radio transmissions over a noisy and shared medium. Also, think about what we just did for noisy channels) Detection: the receiver and/or the sender must be able to determine that a packet was lost (how?) ACKs, retransmission, and sequence numbers: lost packets can be easily treated as corrupted packets c 2005–2008 Antonio Carzaniga
  • 163. Sender Using Timeouts S0 c 2005–2008 Antonio Carzaniga
  • 164. Sender Using Timeouts r send(data) data pkt = [0, data]∗ u send(data pkt) start timer() S0 ACK0 c 2005–2008 Antonio Carzaniga
  • 165. Sender Using Timeouts timeout r send(data) u send(data pkt) data pkt = [0, data]∗ start timer() u send(data pkt) start timer() S0 ACK0 c 2005–2008 Antonio Carzaniga
  • 166. Sender Using Timeouts timeout r send(data) u send(data pkt) data pkt = [0, data]∗ start timer() u send(data pkt) u recv(pkt) start timer() and (pkt = (ACK, 1) S0 ACK0 or pkt is corrupted) u send(data pkt) start timer() c 2005–2008 Antonio Carzaniga
  • 167. Sender Using Timeouts timeout r send(data) u send(data pkt) data pkt = [0, data]∗ start timer() u send(data pkt) u recv(pkt) start timer() and (pkt = (ACK, 1) S0 ACK0 or pkt is corrupted) u send(data pkt) start timer() u recv(pkt) and pkt is good and pkt = (ACK, 0) S1 c 2005–2008 Antonio Carzaniga
  • 168. Sender Using Timeouts timeout r send(data) u send(data pkt) data pkt = [0, data]∗ start timer() u send(data pkt) u recv(pkt) start timer() and (pkt = (ACK, 1) S0 ACK0 or pkt is corrupted) u send(data pkt) start timer() u recv(pkt) and pkt is good and pkt = (ACK, 0) ACK1 S1 r send(data) data pkt = [1, data]∗ u send(data pkt) start timer() c 2005–2008 Antonio Carzaniga
  • 169. Sender Using Timeouts timeout r send(data) u send(data pkt) data pkt = [0, data]∗ start timer() u send(data pkt) u recv(pkt) start timer() and (pkt = (ACK, 1) S0 ACK0 or pkt is corrupted) u send(data pkt) start timer() u recv(pkt) and pkt is good and pkt = (ACK, 0) ACK1 S1 r send(data) data pkt = [1, data]∗ timeout u send(data pkt) u send(data pkt) start timer() start timer() c 2005–2008 Antonio Carzaniga
  • 170. Sender Using Timeouts timeout r send(data) u send(data pkt) data pkt = [0, data]∗ start timer() u send(data pkt) u recv(pkt) start timer() and (pkt = (ACK, 1) S0 ACK0 or pkt is corrupted) u send(data pkt) start timer() u recv(pkt) and pkt is good u recv(pkt) and pkt = (ACK, 0) and (pkt = (ACK, 0) or pkt is corrupted) ACK1 S1 u send(data pkt) start timer() r send(data) data pkt = [1, data]∗ timeout u send(data pkt) u send(data pkt) start timer() start timer() c 2005–2008 Antonio Carzaniga
  • 171. Sender Using Timeouts timeout r send(data) u send(data pkt) data pkt = [0, data]∗ start timer() u send(data pkt) u recv(pkt) start timer() and (pkt = (ACK, 1) S0 ACK0 or pkt is corrupted) u recv(pkt) u send(data pkt) and pkt is good start timer() and pkt = (ACK, 1) u recv(pkt) and pkt is good u recv(pkt) and pkt = (ACK, 0) and (pkt = (ACK, 0) or pkt is corrupted) ACK1 S1 u send(data pkt) start timer() r send(data) data pkt = [1, data]∗ timeout u send(data pkt) u send(data pkt) start timer() start timer() c 2005–2008 Antonio Carzaniga
  • 172. Part II Efficient and Reliable Streams c 2005–2008 Antonio Carzaniga
  • 173. Quantifying Data Transfer How do we measure the “speed” and “capacity” of a network connection? c 2005–2008 Antonio Carzaniga
  • 174. Quantifying Data Transfer How do we measure the “speed” and “capacity” of a network connection? Intuition ◮ water moves in a pipeline ◮ cars move on a road c 2005–2008 Antonio Carzaniga
  • 175. Quantifying Data Transfer How do we measure the “speed” and “capacity” of a network connection? Intuition ◮ water moves in a pipeline ◮ cars move on a road Latency ◮ the time it takes for one bit to go through the connection (from one end to the other) c 2005–2008 Antonio Carzaniga
  • 176. Quantifying Data Transfer How do we measure the “speed” and “capacity” of a network connection? Intuition ◮ water moves in a pipeline ◮ cars move on a road Latency ◮ the time it takes for one bit to go through the connection (from one end to the other) Throughput ◮ the amount of information that can get into (or out of) the connection in a time unit ◮ at “steady-state” we assume zero accumulation of traffic, therefore the input throughput is the same as the output throughput c 2005–2008 Antonio Carzaniga
  • 177. Latency and Throughput connection c 2005–2008 Antonio Carzaniga
  • 178. Latency and Throughput connection message 100 · · · 110 c 2005–2008 Antonio Carzaniga
  • 179. Latency and Throughput connection 100 · · · 110 t0 c 2005–2008 Antonio Carzaniga
  • 180. Latency and Throughput connection 100 · · · 110 t0 t1 c 2005–2008 Antonio Carzaniga
  • 181. Latency and Throughput connection 100 · · · 110 t0 t1 t2 c 2005–2008 Antonio Carzaniga
  • 182. Latency and Throughput connection n bits 100 · · · 110 t0 t1 t2 c 2005–2008 Antonio Carzaniga
  • 183. Latency and Throughput connection n bits 100 · · · 110 t0 t1 t2 Latency L = t1 − t0 sec c 2005–2008 Antonio Carzaniga
  • 184. Latency and Throughput connection n bits 100 · · · 110 t0 t1 t2 Latency L = t1 − t0 sec n Throughput T = bits/sec t2 − t1 c 2005–2008 Antonio Carzaniga
  • 185. Latency and Throughput connection n bits 100 · · · 110 t0 t1 t2 Latency L = t1 − t0 sec n Throughput T = bits/sec t2 − t1 n Transfer time ∆ = L+ sec T c 2005–2008 Antonio Carzaniga
  • 186. Examples How long does it take to tranfer a file between, say, Lugano and St. Petersburg? c 2005–2008 Antonio Carzaniga
  • 187. Examples How long does it take to tranfer a file between, say, Lugano and St. Petersburg? How big is this file? And how fast is our connection? c 2005–2008 Antonio Carzaniga
  • 188. Examples How long does it take to tranfer a file between, say, Lugano and St. Petersburg? How big is this file? And how fast is our connection? E.g., a (short) e-mail message S = 4Kb L = 500ms T = 1Mb/s ∆ = ? c 2005–2008 Antonio Carzaniga
  • 189. Examples How long does it take to tranfer a file between, say, Lugano and St. Petersburg? How big is this file? And how fast is our connection? E.g., a (short) e-mail message S = 4Kb L = 500ms T = 1Mb/s ∆ = 500ms + 4ms = 504ms c 2005–2008 Antonio Carzaniga
  • 190. Examples How about a big file? (E.g., a CD) c 2005–2008 Antonio Carzaniga
  • 191. Examples How about a big file? (E.g., a CD) S = 400Mb L = 500ms T = 1Mb /s ∆ = ? c 2005–2008 Antonio Carzaniga
  • 192. Examples How about a big file? (E.g., a CD) S = 400Mb L = 500ms T = 1Mb /s ∆ = 500ms + 400s = 400.5s = 6′ 40′′ c 2005–2008 Antonio Carzaniga
  • 193. Examples How about a big file? (E.g., a CD) S = 400Mb L = 500ms T = 1Mb /s ∆ = 500ms + 400s = 400.5s = 6′ 40′′ How about a bigger file? (E.g., 10 DVDs) c 2005–2008 Antonio Carzaniga
  • 194. Examples How about a big file? (E.g., a CD) S = 400Mb L = 500ms T = 1Mb /s ∆ = 500ms + 400s = 400.5s = 6′ 40′′ How about a bigger file? (E.g., 10 DVDs) S = 40Gb L = 500ms T = 1Mb /s ∆ = ? c 2005–2008 Antonio Carzaniga
  • 195. Examples How about a big file? (E.g., a CD) S = 400Mb L = 500ms T = 1Mb /s ∆ = 500ms + 400s = 400.5s = 6′ 40′′ How about a bigger file? (E.g., 10 DVDs) S = 40Gb L = 500ms T = 1Mb /s ∆ = ǫ + 40000s = 11h 6′ 40′′ c 2005–2008 Antonio Carzaniga
  • 196. Examples How about flying to St. Petersburgh? c 2005–2008 Antonio Carzaniga
  • 197. Examples How about flying to St. Petersburgh? ◮ assuming you can carry more or less 100 DVDs in your backpack ◮ assuming it takes you four seconds to take the DVDs out of your backpack c 2005–2008 Antonio Carzaniga
  • 198. Examples How about flying to St. Petersburgh? ◮ assuming you can carry more or less 100 DVDs in your backpack ◮ assuming it takes you four seconds to take the DVDs out of your backpack S = 40Gb L = ? T = ∆ = c 2005–2008 Antonio Carzaniga
  • 199. Examples How about flying to St. Petersburgh? ◮ assuming you can carry more or less 100 DVDs in your backpack ◮ assuming it takes you four seconds to take the DVDs out of your backpack S = 40Gb L = 6h T = ? ∆ = c 2005–2008 Antonio Carzaniga
  • 200. Examples How about flying to St. Petersburgh? ◮ assuming you can carry more or less 100 DVDs in your backpack ◮ assuming it takes you four seconds to take the DVDs out of your backpack S = 40Gb L = 6h T = 100Gb /s ∆ = ? c 2005–2008 Antonio Carzaniga
  • 201. Examples How about flying to St. Petersburgh? ◮ assuming you can carry more or less 100 DVDs in your backpack ◮ assuming it takes you four seconds to take the DVDs out of your backpack S = 40Gb L = 6h T = 100Gb /s ∆ = 6h c 2005–2008 Antonio Carzaniga
  • 202. Examples How about flying to St. Petersburgh? ◮ assuming you can carry more or less 100 DVDs in your backpack ◮ assuming it takes you four seconds to take the DVDs out of your backpack S = 40Gb L = 6h T = 100Gb /s ∆ = 6h If you need to transfer 10 DVDs from Lugano to St. Petersburg and time is of the essence (and you have plenty of money). . . then you’re better off talking a plane rather than using the Internet c 2005–2008 Antonio Carzaniga
  • 203. Back to Reliable Data Tranfer c 2005–2008 Antonio Carzaniga
  • 204. Back to Reliable Data Tranfer r send(data) timeout data pkt = [0, data] ∗ u send(data pkt) u send(data pkt) start timer() start timer() u recv(pkt) u recv(pkt) S0 ACK0 and (pkt is corrupted or pkt = (ACK, 1)) u recv(pkt) u recv(pkt) and pkt is good and pkt is good and pkt = (ACK, 1) and pkt = (ACK, 0) u recv(pkt) and (pkt is corrupted ACK1 S1 u recv(pkt) or pkt = (ACK, 0)) r send(data) timeout data pkt = [1, data]∗ u send(data pkt) u send(data pkt) start timer() start timer() c 2005–2008 Antonio Carzaniga
  • 205. Back to Reliable Data Tranfer r send(data) timeout data pkt = [0, data] ∗ u send(data pkt) u send(data pkt) start timer() start timer() u recv(pkt) u recv(pkt) S0 ACK0 and (pkt is corrupted or pkt = (ACK, 1)) u recv(pkt) u recv(pkt) and pkt is good and pkt is good and pkt = (ACK, 1) and pkt = (ACK, 0) u recv(pkt) and (pkt is corrupted ACK1 S1 u recv(pkt) or pkt = (ACK, 0)) r send(data) timeout data pkt = [1, data]∗ u send(data pkt) u send(data pkt) start timer() start timer() c 2005–2008 Antonio Carzaniga
  • 206. Back to Reliable Data Tranfer r send(data) timeout data pkt = [0, data] ∗ u send(data pkt) u send(data pkt) start timer() start timer() u recv(pkt) u recv(pkt) S0 ACK0 and (pkt is corrupted or pkt = (ACK, 1)) u recv(pkt) u recv(pkt) and pkt is good and pkt is good and pkt = (ACK, 1) and pkt = (ACK, 0) u recv(pkt) and (pkt is corrupted ACK1 S1 u recv(pkt) or pkt = (ACK, 0)) r send(data) timeout data pkt = [1, data]∗ u send(data pkt) u send(data pkt) start timer() start timer() c 2005–2008 Antonio Carzaniga
  • 207. Back to Reliable Data Tranfer r send(data) timeout data pkt = [0, data] ∗ u send(data pkt) u send(data pkt) start timer() start timer() u recv(pkt) u recv(pkt) S0 ACK0 and (pkt is corrupted or pkt = (ACK, 1)) u recv(pkt) u recv(pkt) and pkt is good and pkt is good and pkt = (ACK, 1) and pkt = (ACK, 0) u recv(pkt) and (pkt is corrupted ACK1 S1 u recv(pkt) or pkt = (ACK, 0)) r send(data) timeout data pkt = [1, data]∗ u send(data pkt) u send(data pkt) start timer() start timer() c 2005–2008 Antonio Carzaniga
  • 208. Back to Reliable Data Tranfer r send(data) timeout data pkt = [0, data] ∗ u send(data pkt) u send(data pkt) start timer() start timer() u recv(pkt) u recv(pkt) S0 ACK0 and (pkt is corrupted or pkt = (ACK, 1)) u recv(pkt) u recv(pkt) and pkt is good and pkt is good and pkt = (ACK, 1) and pkt = (ACK, 0) u recv(pkt) and (pkt is corrupted ACK1 S1 u recv(pkt) or pkt = (ACK, 0)) r send(data) timeout data pkt = [1, data]∗ u send(data pkt) u send(data pkt) start timer() start timer() c 2005–2008 Antonio Carzaniga
  • 209. Back to Reliable Data Tranfer r send(data) timeout data pkt = [0, data] ∗ u send(data pkt) u send(data pkt) start timer() start timer() u recv(pkt) u recv(pkt) S0 ACK0 and (pkt is corrupted or pkt = (ACK, 1)) u recv(pkt) u recv(pkt) and pkt is good and pkt is good and pkt = (ACK, 1) and pkt = (ACK, 0) u recv(pkt) and (pkt is corrupted ACK1 S1 u recv(pkt) or pkt = (ACK, 0)) r send(data) timeout data pkt = [1, data]∗ u send(data pkt) u send(data pkt) start timer() start timer() c 2005–2008 Antonio Carzaniga
  • 210. Back to Reliable Data Tranfer r send(data) timeout data pkt = [0, data] ∗ u send(data pkt) u send(data pkt) start timer() start timer() u recv(pkt) u recv(pkt) S0 ACK0 and (pkt is corrupted or pkt = (ACK, 1)) u recv(pkt) u recv(pkt) and pkt is good and pkt is good and pkt = (ACK, 1) and pkt = (ACK, 0) u recv(pkt) and (pkt is corrupted ACK1 S1 u recv(pkt) or pkt = (ACK, 0)) r send(data) timeout data pkt = [1, data]∗ u send(data pkt) u send(data pkt) start timer() start timer() c 2005–2008 Antonio Carzaniga
  • 211. Back to Reliable Data Tranfer r send(data) timeout data pkt = [0, data] ∗ u send(data pkt) u send(data pkt) start timer() start timer() u recv(pkt) u recv(pkt) S0 ACK0 and (pkt is corrupted or pkt = (ACK, 1)) u recv(pkt) u recv(pkt) and pkt is good and pkt is good and pkt = (ACK, 1) and pkt = (ACK, 0) u recv(pkt) and (pkt is corrupted ACK1 S1 u recv(pkt) or pkt = (ACK, 0)) r send(data) timeout data pkt = [1, data]∗ u send(data pkt) u send(data pkt) start timer() start timer() c 2005–2008 Antonio Carzaniga
  • 212. Back to Reliable Data Tranfer r send(data) timeout data pkt = [0, data] ∗ u send(data pkt) u send(data pkt) start timer() start timer() u recv(pkt) u recv(pkt) S0 ACK0 and (pkt is corrupted or pkt = (ACK, 1)) u recv(pkt) u recv(pkt) and pkt is good and pkt is good and pkt = (ACK, 1) and pkt = (ACK, 0) u recv(pkt) and (pkt is corrupted ACK1 S1 u recv(pkt) or pkt = (ACK, 0)) r send(data) timeout data pkt = [1, data]∗ u send(data pkt) u send(data pkt) start timer() start timer() c 2005–2008 Antonio Carzaniga
  • 213. Back to Reliable Data Tranfer r send(data) timeout data pkt = [0, data] ∗ u send(data pkt) u send(data pkt) start timer() start timer() u recv(pkt) u recv(pkt) S0 ACK0 and (pkt is corrupted or pkt = (ACK, 1)) u recv(pkt) u recv(pkt) and pkt is good and pkt is good and pkt = (ACK, 1) and pkt = (ACK, 0) u recv(pkt) and (pkt is corrupted ACK1 S1 u recv(pkt) or pkt = (ACK, 0)) r send(data) timeout data pkt = [1, data]∗ u send(data pkt) u send(data pkt) start timer() start timer() c 2005–2008 Antonio Carzaniga
  • 214. Network Usage sender receiver r send(pkt1 ) c 2005–2008 Antonio Carzaniga
  • 215. Network Usage sender receiver r send(pkt1 ) u send([pkt1 ,0]) c 2005–2008 Antonio Carzaniga
  • 216. Network Usage sender receiver r send(pkt1 ) u send([pkt1 ,0]) [pkt 1 ,0 ] c 2005–2008 Antonio Carzaniga
  • 217. Network Usage sender receiver r send(pkt1 ) u send([pkt1 ,0]) [pkt 1 ,0 ] u send([ACK,0]) r recv(pkt1 ) c 2005–2008 Antonio Carzaniga
  • 218. Network Usage sender receiver r send(pkt1 ) u send([pkt1 ,0]) [pkt 1 ,0 ] u send([ACK,0]) ,0 ] [ACK r recv(pkt1 ) c 2005–2008 Antonio Carzaniga
  • 219. Network Usage sender receiver r send(pkt1 ) u send([pkt1 ,0]) [pkt 1 ,0 ] u send([ACK,0]) ,0 ] r send(pkt2 ) [ACK r recv(pkt1 ) c 2005–2008 Antonio Carzaniga
  • 220. Network Usage sender receiver r send(pkt1 ) u send([pkt1 ,0]) [pkt 1 ,0 ] u send([ACK,0]) ,0 ] r send(pkt2 ) [ACK r recv(pkt1 ) u send([pkt2 ,1]) c 2005–2008 Antonio Carzaniga
  • 221. Network Usage sender receiver r send(pkt1 ) u send([pkt1 ,0]) [pkt 1 ,0 ] u send([ACK,0]) ,0 ] r send(pkt2 ) [ACK r recv(pkt1 ) u send([pkt2 ,1]) [pkt 2 ,1 ] c 2005–2008 Antonio Carzaniga
  • 222. Network Usage sender receiver r send(pkt1 ) u send([pkt1 ,0]) [pkt 1 ,0 ] u send([ACK,0]) ,0 ] r send(pkt2 ) [ACK r recv(pkt1 ) u send([pkt2 ,1]) [pkt 2 ,1 ] u send([ACK,1]) r recv(pkt2 ) c 2005–2008 Antonio Carzaniga
  • 223. Network Usage sender receiver r send(pkt1 ) u send([pkt1 ,0]) [pkt 1 ,0 ] u send([ACK,0]) ,0 ] r send(pkt2 ) [ACK r recv(pkt1 ) u send([pkt2 ,1]) [pkt 2 ,1 ] u send([ACK,1]) ,1 ] [ACK r recv(pkt2 ) c 2005–2008 Antonio Carzaniga
  • 224. Network Usage sender receiver [pkt 1 ,0 ] ,0 ] [ACK [pkt 2 ,1 ] ,1 ] [ACK c 2005–2008 Antonio Carzaniga
  • 225. Network Usage sender receiver [pkt 1 ,0 ] ,0 ] [ACK [pkt 2 ,1 ] ,1 ] [ACK c 2005–2008 Antonio Carzaniga
  • 226. Network Usage sender receiver [pkt 1 ,0 ] L ,0 ] [ACK [pkt 2 ,1 ] ,1 ] [ACK c 2005–2008 Antonio Carzaniga
  • 227. Network Usage sender receiver [pkt 1 ,0 ] L Spkt1 /T ,0 ] [ACK [pkt 2 ,1 ] ,1 ] [ACK c 2005–2008 Antonio Carzaniga
  • 228. Network Usage sender receiver [pkt 1 ,0 ] L Spkt1 /T ,0 ] [ACK L [pkt 2 ,1 ] ,1 ] [ACK c 2005–2008 Antonio Carzaniga
  • 229. Network Usage sender receiver [pkt 1 ,0 ] utilization L factor Spkt1 /T Spkt /T ,0 ] U= 2L+Spkt /T [ACK L [pkt 2 ,1 ] ,1 ] [ACK c 2005–2008 Antonio Carzaniga
  • 230. Improving Network Usage How do we achieve a better utilization factor? c 2005–2008 Antonio Carzaniga
  • 231. Improving Network Usage How do we achieve a better utilization factor? sender receiver [pkt 1 ,0 ] ,0 ] [ACK c 2005–2008 Antonio Carzaniga
  • 232. Improving Network Usage How do we achieve a better utilization factor? sender receiver [pkt 1 ,0 ] [pkt 2 ,1 ] ,0 ] [ACK ,1 ] [ACK c 2005–2008 Antonio Carzaniga
  • 233. Improving Network Usage How do we achieve a better utilization factor? sender receiver [pkt 1 ,0 ] [pkt 2 ,1 ] ··· ,0 ] [ACK ,1 ] [ACK ··· c 2005–2008 Antonio Carzaniga
  • 234. Improving Network Usage How do we achieve a better utilization factor? sender receiver [pkt 1 ,0 ] [pkt 2 ,1 ] ··· [pkt w ,w − 1] ,0 ] [ACK ,1 ] [ACK ··· 1] ,w − [ACK c 2005–2008 Antonio Carzaniga
  • 235. Go-Back-N Idea: the sender transmits multiple packets without waiting for an acknowledgement c 2005–2008 Antonio Carzaniga
  • 236. Go-Back-N Idea: the sender transmits multiple packets without waiting for an acknowledgement The sender has up to W unacknowledged packets in the pipeline ◮ the sender’s state machine gets very complex ◮ we represent the sender’s state with its queue of acknowledgements c 2005–2008 Antonio Carzaniga
  • 237. Go-Back-N Idea: the sender transmits multiple packets without waiting for an acknowledgement The sender has up to W unacknowledged packets in the pipeline ◮ the sender’s state machine gets very complex ◮ we represent the sender’s state with its queue of acknowledgements c 2005–2008 Antonio Carzaniga
  • 238. Go-Back-N Idea: the sender transmits multiple packets without waiting for an acknowledgement The sender has up to W unacknowledged packets in the pipeline ◮ the sender’s state machine gets very complex ◮ we represent the sender’s state with its queue of acknowledgements acknowledged pending available unavailable c 2005–2008 Antonio Carzaniga
  • 239. Go-Back-N Idea: the sender transmits multiple packets without waiting for an acknowledgement The sender has up to W unacknowledged packets in the pipeline ◮ the sender’s state machine gets very complex ◮ we represent the sender’s state with its queue of acknowledgements acknowledged pending available unavailable first pending acknowledgement (base) c 2005–2008 Antonio Carzaniga
  • 240. Go-Back-N Idea: the sender transmits multiple packets without waiting for an acknowledgement The sender has up to W unacknowledged packets in the pipeline ◮ the sender’s state machine gets very complex ◮ we represent the sender’s state with its queue of acknowledgements acknowledged pending available unavailable first pending next available acknowledgement sequence number (base) (next seq num) c 2005–2008 Antonio Carzaniga
  • 241. Go-Back-N Idea: the sender transmits multiple packets without waiting for an acknowledgement The sender has up to W unacknowledged packets in the pipeline ◮ the sender’s state machine gets very complex ◮ we represent the sender’s state with its queue of acknowledgements acknowledged pending available unavailable first pending next available acknowledgement sequence number (base) (next seq num) window size (W ) c 2005–2008 Antonio Carzaniga
  • 242. Sliding Window Protocol: Sender base next seq num sliding window c 2005–2008 Antonio Carzaniga
  • 243. Sliding Window Protocol: Sender base next seq num sliding window r send(pkt1 ) c 2005–2008 Antonio Carzaniga
  • 244. Sliding Window Protocol: Sender base next seq num sliding window r send(pkt1 ) ◮ u send([pkt1 ,next seq num]) c 2005–2008 Antonio Carzaniga
  • 245. Sliding Window Protocol: Sender base next seq num sliding window r send(pkt1 ) ◮ u send([pkt1 ,next seq num]) ◮ next seq num ← next seq num + 1 c 2005–2008 Antonio Carzaniga
  • 246. Sliding Window Protocol: Sender A base next seq num sliding window r send(pkt1 ) ◮ u send([pkt1 ,next seq num]) ◮ next seq num ← next seq num + 1 u recv([ACK,A]) c 2005–2008 Antonio Carzaniga
  • 247. Sliding Window Protocol: Sender A base next seq num sliding window r send(pkt1 ) ◮ u send([pkt1 ,next seq num]) ◮ next seq num ← next seq num + 1 u recv([ACK,A]) ◮ base ← A + 1 c 2005–2008 Antonio Carzaniga
  • 248. Sliding Window Protocol: Sender A base next seq num sliding window r send(pkt1 ) ◮ u send([pkt1 ,next seq num]) ◮ next seq num ← next seq num + 1 u recv([ACK,A]) ◮ base ← A + 1 ◮ notice that acknewledgements are “cumulative” c 2005–2008 Antonio Carzaniga
  • 249. Sliding Window Protocol: Sender c 2005–2008 Antonio Carzaniga
  • 250. Sliding Window Protocol: Sender The sender remembers the first sequence number that has not yet been acknowledged ◮ or the highest acknowledged sequence number The sender remembers the first available sequence number ◮ or the highest used sequence number (i.e., sent to the receiver) The sender responds to three types of events c 2005–2008 Antonio Carzaniga
  • 251. Sliding Window Protocol: Sender The sender remembers the first sequence number that has not yet been acknowledged ◮ or the highest acknowledged sequence number The sender remembers the first available sequence number ◮ or the highest used sequence number (i.e., sent to the receiver) The sender responds to three types of events ◮ r send(): invocation from the application layer: send more data if a sequence number is available c 2005–2008 Antonio Carzaniga
  • 252. Sliding Window Protocol: Sender The sender remembers the first sequence number that has not yet been acknowledged ◮ or the highest acknowledged sequence number The sender remembers the first available sequence number ◮ or the highest used sequence number (i.e., sent to the receiver) The sender responds to three types of events ◮ r send(): invocation from the application layer: send more data if a sequence number is available ◮ ACK: receipt of an acknowledgement: shift the window (it’s a “cumulative” ACK) c 2005–2008 Antonio Carzaniga
  • 253. Sliding Window Protocol: Sender The sender remembers the first sequence number that has not yet been acknowledged ◮ or the highest acknowledged sequence number The sender remembers the first available sequence number ◮ or the highest used sequence number (i.e., sent to the receiver) The sender responds to three types of events ◮ r send(): invocation from the application layer: send more data if a sequence number is available ◮ ACK: receipt of an acknowledgement: shift the window (it’s a “cumulative” ACK) ◮ timeout: “Go-Back-N.” I.e., resend all the packets that have been sent but not acknowledged c 2005–2008 Antonio Carzaniga
  • 254. Sliding Window Protocol: Sender init base ← 1 next seq num ← 1 c 2005–2008 Antonio Carzaniga
  • 255. Sliding Window Protocol: Sender init base ← 1 next seq num ← 1 r send(data) if (next seq num < base + W ) { pkt[next seq num] ← [next seq num, data]∗ u send(pkt[next seq num]) if (next seq num = base) { start timer() } next seq num ← next seq num + 1 } else { refuse data(data) // block the sender } c 2005–2008 Antonio Carzaniga
  • 256. Sliding Window Protocol: Sender u recv(pkt) and pkt is corrupted c 2005–2008 Antonio Carzaniga
  • 257. Sliding Window Protocol: Sender u recv(pkt) and pkt is corrupted u recv(ACK,ack num) base ← ack num + 1 // resume the sender if (next seq num = base) { stop timer() } else { start timer() } c 2005–2008 Antonio Carzaniga
  • 258. Sliding Window Protocol: Sender u recv(pkt) and pkt is corrupted u recv(ACK,ack num) base ← ack num + 1 // resume the sender if (next seq num = base) { stop timer() } else { start timer() } timeout start timer() foreach i in base . . . next seq num − 1 { u send(pkt[i]) } c 2005–2008 Antonio Carzaniga
  • 259. Sliding Window Protocol: Receiver c 2005–2008 Antonio Carzaniga
  • 260. Sliding Window Protocol: Receiver Simple: as in the stop-and-wait case, the receiver maintains a counter representing the expected sequence number c 2005–2008 Antonio Carzaniga
  • 261. Sliding Window Protocol: Receiver Simple: as in the stop-and-wait case, the receiver maintains a counter representing the expected sequence number The receiver waits for a (good) data packet with the expected sequence number c 2005–2008 Antonio Carzaniga
  • 262. Sliding Window Protocol: Receiver Simple: as in the stop-and-wait case, the receiver maintains a counter representing the expected sequence number The receiver waits for a (good) data packet with the expected sequence number ◮ acknowledges the expected sequence number c 2005–2008 Antonio Carzaniga
  • 263. Sliding Window Protocol: Receiver Simple: as in the stop-and-wait case, the receiver maintains a counter representing the expected sequence number The receiver waits for a (good) data packet with the expected sequence number ◮ acknowledges the expected sequence number ◮ delivers the data to the application c 2005–2008 Antonio Carzaniga
  • 264. Sliding Window Protocol: Receiver init expected seq num ← 1 ackpkt ← [ACK , 0]∗ c 2005–2008 Antonio Carzaniga
  • 265. Sliding Window Protocol: Receiver init expected seq num ← 1 ackpkt ← [ACK , 0]∗ u recv([data, seq num]) and good and seq num = expected seq num r recv(data) ackpkt ← [ACK , expected seq num]∗ expected seq num ← expected seq num + 1 u send(ackpkt) c 2005–2008 Antonio Carzaniga
  • 266. Sliding Window Protocol: Receiver init expected seq num ← 1 ackpkt ← [ACK , 0]∗ u recv([data, seq num]) and good and seq num = expected seq num r recv(data) ackpkt ← [ACK , expected seq num]∗ expected seq num ← expected seq num + 1 u send(ackpkt) u recv([data, seq num]) and (corrupted or seq num = expected seq num) u send(ackpkt) c 2005–2008 Antonio Carzaniga
  • 267. Comments Concepts c 2005–2008 Antonio Carzaniga
  • 268. Comments Concepts ◮ sequence numbers c 2005–2008 Antonio Carzaniga
  • 269. Comments Concepts ◮ sequence numbers ◮ sliding window c 2005–2008 Antonio Carzaniga
  • 270. Comments Concepts ◮ sequence numbers ◮ sliding window ◮ cumulative acknowledgements c 2005–2008 Antonio Carzaniga
  • 271. Comments Concepts ◮ sequence numbers ◮ sliding window ◮ cumulative acknowledgements ◮ checksums, timeouts, and sender-initiated retransmission c 2005–2008 Antonio Carzaniga
  • 272. Comments Concepts ◮ sequence numbers ◮ sliding window ◮ cumulative acknowledgements ◮ checksums, timeouts, and sender-initiated retransmission Advantages: simple c 2005–2008 Antonio Carzaniga
  • 273. Comments Concepts ◮ sequence numbers ◮ sliding window ◮ cumulative acknowledgements ◮ checksums, timeouts, and sender-initiated retransmission Advantages: simple ◮ the sender maintains two counters and a one timer ◮ the receiver maintains one counter c 2005–2008 Antonio Carzaniga
  • 274. Comments Concepts ◮ sequence numbers ◮ sliding window ◮ cumulative acknowledgements ◮ checksums, timeouts, and sender-initiated retransmission Advantages: simple ◮ the sender maintains two counters and a one timer ◮ the receiver maintains one counter Disadvantages: not optimal, not adaptive c 2005–2008 Antonio Carzaniga
  • 275. Comments Concepts ◮ sequence numbers ◮ sliding window ◮ cumulative acknowledgements ◮ checksums, timeouts, and sender-initiated retransmission Advantages: simple ◮ the sender maintains two counters and a one timer ◮ the receiver maintains one counter Disadvantages: not optimal, not adaptive ◮ the sender can fill the window without filling the pipeline c 2005–2008 Antonio Carzaniga
  • 276. Comments Concepts ◮ sequence numbers ◮ sliding window ◮ cumulative acknowledgements ◮ checksums, timeouts, and sender-initiated retransmission Advantages: simple ◮ the sender maintains two counters and a one timer ◮ the receiver maintains one counter Disadvantages: not optimal, not adaptive ◮ the sender can fill the window without filling the pipeline ◮ the receiver may buffer out-of-order packets. . . c 2005–2008 Antonio Carzaniga
  • 277. Performance Analysis What is a good value for W ? c 2005–2008 Antonio Carzaniga
  • 278. Performance Analysis What is a good value for W ? ◮ W that achieves the maximum utilization of the connection c 2005–2008 Antonio Carzaniga
  • 279. Performance Analysis What is a good value for W ? ◮ W that achieves the maximum utilization of the connection S = stream L = 500ms T = 1Mb /s W = ? c 2005–2008 Antonio Carzaniga
  • 280. Performance Analysis What is a good value for W ? ◮ W that achieves the maximum utilization of the connection S = stream L = 500ms T = 1Mb /s W = ? The problem may seem a bit underspecified. What is the (average) packet size? Spkr = 1Kb L = 500ms T = 1Mb /s 2L×T W = Spkt = 1000 c 2005–2008 Antonio Carzaniga
  • 281. Performance Analysis The RTT–throughput product (2L × T ) is the crucial factor c 2005–2008 Antonio Carzaniga
  • 282. Performance Analysis The RTT–throughput product (2L × T ) is the crucial factor ◮ W × Spkt ≤ 2L × T ◮ why W × Spkt > 2L × T doesn’t make much sense? c 2005–2008 Antonio Carzaniga
  • 283. Performance Analysis The RTT–throughput product (2L × T ) is the crucial factor ◮ W × Spkt ≤ 2L × T ◮ why W × Spkt > 2L × T doesn’t make much sense? ◮ maximum channel utilization when W × Spkt = 2L × T ◮ 2L × T can be thought of as the capacity of a connection c 2005–2008 Antonio Carzaniga
  • 284. Problems with Go-Back-N Let’s consider a fully utilized connection c 2005–2008 Antonio Carzaniga
  • 285. Problems with Go-Back-N Let’s consider a fully utilized connection Spkr = 1Kb L = 500ms T = 1Mb /s T ×L W = Spkt = 1000 c 2005–2008 Antonio Carzaniga
  • 286. Problems with Go-Back-N Let’s consider a fully utilized connection Spkr = 1Kb L = 500ms T = 1Mb /s T ×L W = Spkt = 1000 What happens if the first packet (or acknowledgement) is lost? c 2005–2008 Antonio Carzaniga
  • 287. Problems with Go-Back-N Let’s consider a fully utilized connection Spkr = 1Kb L = 500ms T = 1Mb /s T ×L W = Spkt = 1000 What happens if the first packet (or acknowledgement) is lost? Sender retransmits the entire content of its buffers c 2005–2008 Antonio Carzaniga
  • 288. Problems with Go-Back-N Let’s consider a fully utilized connection Spkr = 1Kb L = 500ms T = 1Mb /s T ×L W = Spkt = 1000 What happens if the first packet (or acknowledgement) is lost? Sender retransmits the entire content of its buffers ◮ W × Spkt = 2L × T = 1Mb ◮ retransmitting 1Mb to recover 1Kb worth of data isn’t exactly the best solution. Not to mention conjestions. . . c 2005–2008 Antonio Carzaniga
  • 289. Problems with Go-Back-N Let’s consider a fully utilized connection Spkr = 1Kb L = 500ms T = 1Mb /s T ×L W = Spkt = 1000 What happens if the first packet (or acknowledgement) is lost? Sender retransmits the entire content of its buffers ◮ W × Spkt = 2L × T = 1Mb ◮ retransmitting 1Mb to recover 1Kb worth of data isn’t exactly the best solution. Not to mention conjestions. . . Is there a better way to deal with retransmissions? c 2005–2008 Antonio Carzaniga
  • 290. Selective Repeat Idea: have the sender retransmit only those packets that it suspects were lost or corrupted c 2005–2008 Antonio Carzaniga
  • 291. Selective Repeat Idea: have the sender retransmit only those packets that it suspects were lost or corrupted ◮ sender maintains a vector of acknowledgement flags c 2005–2008 Antonio Carzaniga
  • 292. Selective Repeat Idea: have the sender retransmit only those packets that it suspects were lost or corrupted ◮ sender maintains a vector of acknowledgement flags ◮ receiver maintains a vector of acknowledged falgs c 2005–2008 Antonio Carzaniga
  • 293. Selective Repeat Idea: have the sender retransmit only those packets that it suspects were lost or corrupted ◮ sender maintains a vector of acknowledgement flags ◮ receiver maintains a vector of acknowledged falgs ◮ in fact, receiver maintains a buffer of out-of-order packets c 2005–2008 Antonio Carzaniga
  • 294. Selective Repeat Idea: have the sender retransmit only those packets that it suspects were lost or corrupted ◮ sender maintains a vector of acknowledgement flags ◮ receiver maintains a vector of acknowledged falgs ◮ in fact, receiver maintains a buffer of out-of-order packets ◮ sender maintains a timer for each pending packet c 2005–2008 Antonio Carzaniga
  • 295. Selective Repeat Idea: have the sender retransmit only those packets that it suspects were lost or corrupted ◮ sender maintains a vector of acknowledgement flags ◮ receiver maintains a vector of acknowledged falgs ◮ in fact, receiver maintains a buffer of out-of-order packets ◮ sender maintains a timer for each pending packet ◮ sender resends a packet when its timer expires c 2005–2008 Antonio Carzaniga
  • 296. Selective Repeat Idea: have the sender retransmit only those packets that it suspects were lost or corrupted ◮ sender maintains a vector of acknowledgement flags ◮ receiver maintains a vector of acknowledged falgs ◮ in fact, receiver maintains a buffer of out-of-order packets ◮ sender maintains a timer for each pending packet ◮ sender resends a packet when its timer expires ◮ sender slides the window when the lowest pending sequence number is acknowledged c 2005–2008 Antonio Carzaniga
  • 297. Selective Repeat: Sender base next seq num sliding window c 2005–2008 Antonio Carzaniga
  • 298. Selective Repeat: Sender base next seq num sliding window r send(pkt1 ) c 2005–2008 Antonio Carzaniga
  • 299. Selective Repeat: Sender base next seq num sliding window r send(pkt1 ) ◮ u send([pkt1 ,next seq num]) ◮ start timer(next seq num) c 2005–2008 Antonio Carzaniga
  • 300. Selective Repeat: Sender base next seq num sliding window r send(pkt1 ) ◮ u send([pkt1 ,next seq num]) ◮ start timer(next seq num) ◮ next seq num ← next seq num + 1 c 2005–2008 Antonio Carzaniga
  • 301. Selective Repeat: Sender A base next seq num sliding window r send(pkt1 ) ◮ u send([pkt1 ,next seq num]) ◮ start timer(next seq num) ◮ next seq num ← next seq num + 1 u recv([ACK,A]) c 2005–2008 Antonio Carzaniga
  • 302. Selective Repeat: Sender A base next seq num sliding window r send(pkt1 ) ◮ u send([pkt1 ,next seq num]) ◮ start timer(next seq num) ◮ next seq num ← next seq num + 1 u recv([ACK,A]) ◮ acks[A] ← 1 // remember that A was ACK’d c 2005–2008 Antonio Carzaniga
  • 303. Selective Repeat: Sender A base next seq num sliding window r send(pkt1 ) ◮ u send([pkt1 ,next seq num]) ◮ start timer(next seq num) ◮ next seq num ← next seq num + 1 u recv([ACK,A]) ◮ acks[A] ← 1 // remember that A was ACK’d ◮ acknewledgements are no longer “cumulative” c 2005–2008 Antonio Carzaniga
  • 304. Selective Repeat: Receiver c 2005–2008 Antonio Carzaniga
  • 305. Selective Repeat: Receiver received acceptable not usable rcv base sliding window c 2005–2008 Antonio Carzaniga
  • 306. Selective Repeat: Receiver X1 received acceptable not usable rcv base sliding window u recv([pkt1 ,X1 ]) and rcv base ≤ X1 < rcv base + W c 2005–2008 Antonio Carzaniga
  • 307. Selective Repeat: Receiver X1 received acceptable not usable rcv base sliding window u recv([pkt1 ,X1 ]) and rcv base ≤ X1 < rcv base + W ◮ buffer [X1 ] ← pkt1 ◮ u send([ACK , X1 ]∗ ) // no longer a “cumulative” ACK c 2005–2008 Antonio Carzaniga
  • 308. Selective Repeat: Receiver received acceptable not usable rcv base sliding window c 2005–2008 Antonio Carzaniga
  • 309. Selective Repeat: Receiver X2 received acceptable not usable rcv base sliding window u recv([pkt2 ,X2 ]) and rcv base ≤ X2 < rcv base + W ◮ buffer [X ] ← pkt 2 2 ◮ u send([ACK , X2 ]∗ ) c 2005–2008 Antonio Carzaniga
  • 310. Selective Repeat: Receiver X2 received acceptable not usable rcv base sliding window u recv([pkt2 ,X2 ]) and rcv base ≤ X2 < rcv base + W ◮ buffer [X ] ← pkt 2 2 ◮ u send([ACK , X2 ]∗ ) ◮ if (X2 = rcv base) { c 2005–2008 Antonio Carzaniga
  • 311. Selective Repeat: Receiver X2 B received acceptable not usable rcv base sliding window u recv([pkt2 ,X2 ]) and rcv base ≤ X2 < rcv base + W ◮ buffer [X ] ← pkt 2 2 ◮ u send([ACK , X2 ]∗ ) ◮ if (X2 = rcv base) { B ← first missing seq num() foreach i in rcv base . . . B − 1 { r recv(buffer [i]) } c 2005–2008 Antonio Carzaniga
  • 312. Selective Repeat: Receiver received acceptable not usable rcv base sliding window u recv([pkt2 ,X2 ]) and rcv base ≤ X2 < rcv base + W ◮ buffer [X ] ← pkt 2 2 ◮ u send([ACK , X2 ]∗ ) ◮ if (X2 = rcv base) { B ← first missing seq num() foreach i in rcv base . . . B − 1 { r recv(buffer [i]) } rcv base ← B } c 2005–2008 Antonio Carzaniga
  • 313. Selective Repeat: Sender c 2005–2008 Antonio Carzaniga
  • 314. Selective Repeat: Sender base next seq num sliding window c 2005–2008 Antonio Carzaniga
  • 315. Selective Repeat: Sender T base next seq num sliding window Timeout for sequence number T c 2005–2008 Antonio Carzaniga
  • 316. Selective Repeat: Sender T base next seq num sliding window Timeout for sequence number T ◮ u send([pkt[T ], T ]∗) c 2005–2008 Antonio Carzaniga
  • 317. Selective Repeat: Sender base next seq num sliding window c 2005–2008 Antonio Carzaniga
  • 318. Selective Repeat: Sender A base next seq num sliding window u recv([ACK,A]) c 2005–2008 Antonio Carzaniga
  • 319. Selective Repeat: Sender A base next seq num sliding window u recv([ACK,A]) ◮ acks[A] ← 1 c 2005–2008 Antonio Carzaniga
  • 320. Selective Repeat: Sender A base next seq num sliding window u recv([ACK,A]) ◮ acks[A] ← 1 ◮ if (A = base) { c 2005–2008 Antonio Carzaniga
  • 321. Selective Repeat: Sender base next seq num sliding window u recv([ACK,A]) ◮ acks[A] ← 1 ◮ if (A = base) { base ← first missing ack num() } c 2005–2008 Antonio Carzaniga
  • 322. Part III Congestion Control c 2005–2008 Antonio Carzaniga
  • 323. Understanding Congestion A router behaves a lot like a kitchen sink c 2005–2008 Antonio Carzaniga
  • 324. Understanding Congestion A router behaves a lot like a kitchen sink max throughput T c 2005–2008 Antonio Carzaniga
  • 325. Understanding Congestion A router behaves a lot like a kitchen sink λ1 = T /2 max throughput T throughput = T /2 c 2005–2008 Antonio Carzaniga
  • 326. Understanding Congestion A router behaves a lot like a kitchen sink λ1 = T /2 λ2 = T /2 max throughput T throughput = T c 2005–2008 Antonio Carzaniga
  • 327. Understanding Congestion A router behaves a lot like a kitchen sink λ3 = T /2 λ1 = T /2 λ2 = T /2 max throughput T throughput = T c 2005–2008 Antonio Carzaniga
  • 328. Understanding Congestion A router behaves a lot like a kitchen sink λ3 = T /2 λ1 = T /2 λ2 = T /2 max throughput T throughput = T c 2005–2008 Antonio Carzaniga
  • 329. Understanding Congestion A router behaves a lot like a kitchen sink λ3 = T /2 λ1 = T /2 λ2 = T /2 max throughput T throughput = T c 2005–2008 Antonio Carzaniga
  • 330. Understanding Congestion A router behaves a lot like a kitchen sink λ3 = T /2 λ1 = T /2 λ2 = T /2 max throughput T throughput = T c 2005–2008 Antonio Carzaniga
  • 331. Understanding Congestion A router behaves a lot like a kitchen sink λ3 = T /2 λ1 = T /2 λ2 = T /2 max throughput T throughput = T c 2005–2008 Antonio Carzaniga
  • 332. Queuing Delay c 2005–2008 Antonio Carzaniga
  • 333. Queuing Delay Total latency is the sum of link latency, processing time, and the time that a packet spends in the input queue L = ∆TX + ∆CPU + ∆q where ∆q = |q |/T c 2005–2008 Antonio Carzaniga
  • 334. Queuing Delay Total latency is the sum of link latency, processing time, and the time that a packet spends in the input queue L = ∆TX + ∆CPU + ∆q where ∆q = |q |/T Ideal case: constant input data rate λin < T In this case the ∆q = 0, because |q | = 0 c 2005–2008 Antonio Carzaniga
  • 335. Queuing Delay Total latency is the sum of link latency, processing time, and the time that a packet spends in the input queue L = ∆TX + ∆CPU + ∆q where ∆q = |q |/T Ideal case: constant input data rate λin < T In this case the ∆q = 0, because |q | = 0 Extreme case: constant input data rate λin > T In this case |q | = (λin − T )t and therefore λin − T ∆q = t T c 2005–2008 Antonio Carzaniga
  • 336. Queuing Delay c 2005–2008 Antonio Carzaniga
  • 337. Queuing Delay Steady-state queuing delay 0 λin < T ∆q = λin −T T t λin > T c 2005–2008 Antonio Carzaniga
  • 338. Queuing Delay Steady-state queuing delay 0 λin < T ∆q = λin −T T t λin > T ∆q T λin ideal input flow λin constant c 2005–2008 Antonio Carzaniga
  • 339. Queuing Delay Steady-state queuing delay 0 λin < T ∆q = λin −T T t λin > T ∆q ∆q T T λin λin ideal input flow realistic input flow λin constant λin variable c 2005–2008 Antonio Carzaniga
  • 340. Queuing Delay c 2005–2008 Antonio Carzaniga
  • 341. Queuing Delay Conclusion: as the input rate λin approaches the maximum throughput T , packets will experience very long delays c 2005–2008 Antonio Carzaniga
  • 342. Queuing Delay Conclusion: as the input rate λin approaches the maximum throughput T , packets will experience very long delays More realistic assumptions and models ◮ finite queue length (buffers) in routers ◮ effects of retransmission overhead c 2005–2008 Antonio Carzaniga
  • 343. Queuing Delay Conclusion: as the input rate λin approaches the maximum throughput T , packets will experience very long delays More realistic assumptions and models ◮ finite queue length (buffers) in routers ◮ effects of retransmission overhead T λout λin c 2005–2008 Antonio Carzaniga
  • 344. Queuing Delay Conclusion: as the input rate λin approaches the maximum throughput T , packets will experience very long delays More realistic assumptions and models ◮ finite queue length (buffers) in routers ◮ effects of retransmission overhead T congestion λout λin c 2005–2008 Antonio Carzaniga
  • 345. What to Do? What to do when the network is congested and queues are full? λ3 = T /2 λ1 = T /2 λ2 = T /2 max throughput T throughput = T c 2005–2008 Antonio Carzaniga
  • 346. What to Do? What to do when the network is congested and queues are full? λ1 = T /2 max throughput T throughput = T c 2005–2008 Antonio Carzaniga
  • 347. What to Do? What to do when the network is congested and queues are full? λ1 = T /2 max throughput T throughput = T c 2005–2008 Antonio Carzaniga
  • 348. What to Do? What to do when the network is congested and queues are full? λ1 = T /2 max throughput T throughput = T c 2005–2008 Antonio Carzaniga
  • 349. What to Do? What to do when the network is congested and queues are full? λ1 = T /2 max throughput T throughput = T c 2005–2008 Antonio Carzaniga
  • 350. Part IV Brief Overview of TCP c 2005–2008 Antonio Carzaniga
  • 351. Transmission Control Protocol The Internet’s primary transport protocol ◮ defined in RFC 793, RFC 1122, RFC 1323, RFC 2018, and RFC 2581 c 2005–2008 Antonio Carzaniga
  • 352. Transmission Control Protocol The Internet’s primary transport protocol ◮ defined in RFC 793, RFC 1122, RFC 1323, RFC 2018, and RFC 2581 Connection-oriented service ◮ endpoints “shake hands” to establish a connection ◮ not a circuit-switched connection, nor a virtual circuit c 2005–2008 Antonio Carzaniga
  • 353. Transmission Control Protocol The Internet’s primary transport protocol ◮ defined in RFC 793, RFC 1122, RFC 1323, RFC 2018, and RFC 2581 Connection-oriented service ◮ endpoints “shake hands” to establish a connection ◮ not a circuit-switched connection, nor a virtual circuit Full-duplex service ◮ both endpoints can both send and receiver, at the same time c 2005–2008 Antonio Carzaniga
  • 354. Preliminary Definitions c 2005–2008 Antonio Carzaniga
  • 355. Preliminary Definitions TCP segment: envelope for TCP data ◮ TCP data are sent within TCP segments ◮ TCP segments are usually sent within an IP packet c 2005–2008 Antonio Carzaniga
  • 356. Preliminary Definitions TCP segment: envelope for TCP data ◮ TCP data are sent within TCP segments ◮ TCP segments are usually sent within an IP packet Maximum segment size (MSS): maximum amount of application data transmitted in a single segment ◮ typically related to the MTU of the connection, to avoid network-level fragmentation (we’ll talk about all of this later) c 2005–2008 Antonio Carzaniga
  • 357. Preliminary Definitions TCP segment: envelope for TCP data ◮ TCP data are sent within TCP segments ◮ TCP segments are usually sent within an IP packet Maximum segment size (MSS): maximum amount of application data transmitted in a single segment ◮ typically related to the MTU of the connection, to avoid network-level fragmentation (we’ll talk about all of this later) Maximum transmission unit (MTU): largest link-layer frame available to the sender host ◮ path MTU: largest link-layer frame that can be sent on all links from the sender host to the receiver host c 2005–2008 Antonio Carzaniga
  • 358. TCP Segment Format 0 31 source port destination port sequence number acknowledgment number hdrlen unused U A P R S F receive window Internet checksum urgent data pointer options field data c 2005–2008 Antonio Carzaniga
  • 359. TCP Header Fields c 2005–2008 Antonio Carzaniga
  • 360. TCP Header Fields Source and destination ports: (16-bit each) application identifiers c 2005–2008 Antonio Carzaniga
  • 361. TCP Header Fields Source and destination ports: (16-bit each) application identifiers Sequence number: (32-bit) used to implement reliable data transfer Acknowledgment number: (32-bit) used to implement reliable data transfer c 2005–2008 Antonio Carzaniga
  • 362. TCP Header Fields Source and destination ports: (16-bit each) application identifiers Sequence number: (32-bit) used to implement reliable data transfer Acknowledgment number: (32-bit) used to implement reliable data transfer Receive window: (16-bit) size of the “window” on the receiver end c 2005–2008 Antonio Carzaniga
  • 363. TCP Header Fields Source and destination ports: (16-bit each) application identifiers Sequence number: (32-bit) used to implement reliable data transfer Acknowledgment number: (32-bit) used to implement reliable data transfer Receive window: (16-bit) size of the “window” on the receiver end Header length: (4-bit) size of the TCP header in 32-bit words c 2005–2008 Antonio Carzaniga
  • 364. TCP Header Fields Source and destination ports: (16-bit each) application identifiers Sequence number: (32-bit) used to implement reliable data transfer Acknowledgment number: (32-bit) used to implement reliable data transfer Receive window: (16-bit) size of the “window” on the receiver end Header length: (4-bit) size of the TCP header in 32-bit words Optional and variable-length options field: may be used to negotiate protocol parameters c 2005–2008 Antonio Carzaniga
  • 365. TCP Header Fields c 2005–2008 Antonio Carzaniga
  • 366. TCP Header Fields ACK flag: (1-bit) signals that the value contained in the acknowledgment number represents a valid acknowledgment c 2005–2008 Antonio Carzaniga
  • 367. TCP Header Fields ACK flag: (1-bit) signals that the value contained in the acknowledgment number represents a valid acknowledgment SYN flag: (1-bit) used during connection setup and shutdown c 2005–2008 Antonio Carzaniga
  • 368. TCP Header Fields ACK flag: (1-bit) signals that the value contained in the acknowledgment number represents a valid acknowledgment SYN flag: (1-bit) used during connection setup and shutdown RST flag: (1-bit) used during connection setup and shutdown c 2005–2008 Antonio Carzaniga
  • 369. TCP Header Fields ACK flag: (1-bit) signals that the value contained in the acknowledgment number represents a valid acknowledgment SYN flag: (1-bit) used during connection setup and shutdown RST flag: (1-bit) used during connection setup and shutdown FIN flag: (1-bit) used during connection shutdown c 2005–2008 Antonio Carzaniga
  • 370. TCP Header Fields ACK flag: (1-bit) signals that the value contained in the acknowledgment number represents a valid acknowledgment SYN flag: (1-bit) used during connection setup and shutdown RST flag: (1-bit) used during connection setup and shutdown FIN flag: (1-bit) used during connection shutdown PSH flag: (1-bit) “push” flag, used to solicit the receiver to pass the data to the application immediately c 2005–2008 Antonio Carzaniga
  • 371. TCP Header Fields ACK flag: (1-bit) signals that the value contained in the acknowledgment number represents a valid acknowledgment SYN flag: (1-bit) used during connection setup and shutdown RST flag: (1-bit) used during connection setup and shutdown FIN flag: (1-bit) used during connection shutdown PSH flag: (1-bit) “push” flag, used to solicit the receiver to pass the data to the application immediately URG flag: (1-bit) “urgent” flag, used to inform the receiver that the sender has marked some data as “urgent”. The location of this urgent data is marked by the urgent data pointer field c 2005–2008 Antonio Carzaniga
  • 372. TCP Header Fields ACK flag: (1-bit) signals that the value contained in the acknowledgment number represents a valid acknowledgment SYN flag: (1-bit) used during connection setup and shutdown RST flag: (1-bit) used during connection setup and shutdown FIN flag: (1-bit) used during connection shutdown PSH flag: (1-bit) “push” flag, used to solicit the receiver to pass the data to the application immediately URG flag: (1-bit) “urgent” flag, used to inform the receiver that the sender has marked some data as “urgent”. The location of this urgent data is marked by the urgent data pointer field Checksum: (16-bit) used to detect transmission errors c 2005–2008 Antonio Carzaniga
  • 373. Sequence Numbers c 2005–2008 Antonio Carzaniga
  • 374. Sequence Numbers Sequence numbers are associated with bytes in the data stream ◮ not with segments, as we have used them before c 2005–2008 Antonio Carzaniga
  • 375. Sequence Numbers Sequence numbers are associated with bytes in the data stream ◮ not with segments, as we have used them before The sequence number in a TCP segment indicates the sequence number of the first byte carried by that segment c 2005–2008 Antonio Carzaniga
  • 376. Sequence Numbers Sequence numbers are associated with bytes in the data stream ◮ not with segments, as we have used them before The sequence number in a TCP segment indicates the sequence number of the first byte carried by that segment application data stream 4Kb c 2005–2008 Antonio Carzaniga
  • 377. Sequence Numbers Sequence numbers are associated with bytes in the data stream ◮ not with segments, as we have used them before The sequence number in a TCP segment indicates the sequence number of the first byte carried by that segment application data stream 4Kb MSS=1024b c 2005–2008 Antonio Carzaniga
  • 378. Sequence Numbers Sequence numbers are associated with bytes in the data stream ◮ not with segments, as we have used them before The sequence number in a TCP segment indicates the sequence number of the first byte carried by that segment application data stream 4Kb MSS=1024b c 2005–2008 Antonio Carzaniga
  • 379. Sequence Numbers Sequence numbers are associated with bytes in the data stream ◮ not with segments, as we have used them before The sequence number in a TCP segment indicates the sequence number of the first byte carried by that segment application data stream 4Kb MSS=1024b 1. . . . . . 1024 1025. . . 2048 2049. . . 3072 3073. . . 4096 c 2005–2008 Antonio Carzaniga
  • 380. Sequence Numbers Sequence numbers are associated with bytes in the data stream ◮ not with segments, as we have used them before The sequence number in a TCP segment indicates the sequence number of the first byte carried by that segment application data stream 4Kb MSS=1024b 1. . . . . . 1024 1025. . . 2048 2049. . . 3072 3073. . . 4096 a TCP segment c 2005–2008 Antonio Carzaniga
  • 381. Sequence Numbers Sequence numbers are associated with bytes in the data stream ◮ not with segments, as we have used them before The sequence number in a TCP segment indicates the sequence number of the first byte carried by that segment application data stream 4Kb MSS=1024b 1. . . . . . 1024 1025. . . 2048 2049. . . 3072 3073. . . 4096 a TCP segment 2049 c 2005–2008 Antonio Carzaniga
  • 382. Sequence Numbers Sequence numbers are associated with bytes in the data stream ◮ not with segments, as we have used them before The sequence number in a TCP segment indicates the sequence number of the first byte carried by that segment application data stream 4Kb MSS=1024b 1. . . . . . 1024 1025. . . 2048 2049. . . 3072 3073. . . 4096 sequence number a TCP segment 2049 c 2005–2008 Antonio Carzaniga
  • 383. Acknowledgment Numbers c 2005–2008 Antonio Carzaniga
  • 384. Acknowledgment Numbers An acknowledgment number represents the first sequence number not yet seen by the receiver ◮ TCP acknowledgments are cumulative c 2005–2008 Antonio Carzaniga
  • 385. Acknowledgment Numbers An acknowledgment number represents the first sequence number not yet seen by the receiver ◮ TCP acknowledgments are cumulative A B c 2005–2008 Antonio Carzaniga
  • 386. Acknowledgment Numbers An acknowledgment number represents the first sequence number not yet seen by the receiver ◮ TCP acknowledgments are cumulative A B [Seq# = 1200, . . .], size(data) = 1000 c 2005–2008 Antonio Carzaniga
  • 387. Acknowledgment Numbers An acknowledgment number represents the first sequence number not yet seen by the receiver ◮ TCP acknowledgments are cumulative A B [Seq# = 1200, . . .], size(data) = 1000 [Seq# = 2200, . . .], size(data) = 500 c 2005–2008 Antonio Carzaniga
  • 388. Acknowledgment Numbers An acknowledgment number represents the first sequence number not yet seen by the receiver ◮ TCP acknowledgments are cumulative A B [Seq# = 1200, . . .], size(data) = 1000 [Seq# = 2200, . . .], size(data) = 500 [Seq# = . . . , Ack # = 2700] c 2005–2008 Antonio Carzaniga
  • 389. Sequence Numbers and ACK Numbers c 2005–2008 Antonio Carzaniga
  • 390. Sequence Numbers and ACK Numbers Notice that a TCP connection consists of is a full-duplex link ◮ therefore, there are two streams ◮ two different sequence numbers c 2005–2008 Antonio Carzaniga
  • 391. Sequence Numbers and ACK Numbers Notice that a TCP connection consists of is a full-duplex link ◮ therefore, there are two streams ◮ two different sequence numbers E.g., consider a simple “Echo” application: A B c 2005–2008 Antonio Carzaniga
  • 392. Sequence Numbers and ACK Numbers Notice that a TCP connection consists of is a full-duplex link ◮ therefore, there are two streams ◮ two different sequence numbers E.g., consider a simple “Echo” application: A B [Seq# = 100, Data =“C”] c 2005–2008 Antonio Carzaniga
  • 393. Sequence Numbers and ACK Numbers Notice that a TCP connection consists of is a full-duplex link ◮ therefore, there are two streams ◮ two different sequence numbers E.g., consider a simple “Echo” application: A B [Seq# = 100, Data =“C”] [Ack # = 101, Seq# = 200, Data =“C”] c 2005–2008 Antonio Carzaniga
  • 394. Sequence Numbers and ACK Numbers Notice that a TCP connection consists of is a full-duplex link ◮ therefore, there are two streams ◮ two different sequence numbers E.g., consider a simple “Echo” application: A B [Seq# = 100, Data =“C”] [Ack # = 101, Seq# = 200, Data =“C”] [Seq# = 101, Ack # = 201, Data =“i”] c 2005–2008 Antonio Carzaniga
  • 395. Sequence Numbers and ACK Numbers Notice that a TCP connection consists of is a full-duplex link ◮ therefore, there are two streams ◮ two different sequence numbers E.g., consider a simple “Echo” application: A B [Seq# = 100, Data =“C”] [Ack # = 101, Seq# = 200, Data =“C”] [Seq# = 101, Ack # = 201, Data =“i”] [Seq# = 201, Ack # = 102, Data =“i”] c 2005–2008 Antonio Carzaniga
  • 396. Sequence Numbers and ACK Numbers Notice that a TCP connection consists of is a full-duplex link ◮ therefore, there are two streams ◮ two different sequence numbers E.g., consider a simple “Echo” application: A B [Seq# = 100, Data =“C”] [Ack # = 101, Seq# = 200, Data =“C”] [Seq# = 101, Ack # = 201, Data =“i”] [Seq# = 201, Ack # = 102, Data =“i”] Acknowledgments are “piggybacked” on data segments c 2005–2008 Antonio Carzaniga
  • 397. Reliability and Timeout TCP provides reliable data transfer using a timer to detect lost segments ◮ timeout without an ACK → lost packet → retransmission c 2005–2008 Antonio Carzaniga
  • 398. Reliability and Timeout TCP provides reliable data transfer using a timer to detect lost segments ◮ timeout without an ACK → lost packet → retransmission How long to wait for acknowledgments? c 2005–2008 Antonio Carzaniga
  • 399. Reliability and Timeout TCP provides reliable data transfer using a timer to detect lost segments ◮ timeout without an ACK → lost packet → retransmission How long to wait for acknowledgments? Retransmission timeouts should be larger than the round-trip time RTT = 2L ◮ as close as possible to the RTT c 2005–2008 Antonio Carzaniga
  • 400. Reliability and Timeout TCP provides reliable data transfer using a timer to detect lost segments ◮ timeout without an ACK → lost packet → retransmission How long to wait for acknowledgments? Retransmission timeouts should be larger than the round-trip time RTT = 2L ◮ as close as possible to the RTT TCP controls its timeout by continuously estimating the current RTT c 2005–2008 Antonio Carzaniga
  • 401. Round-Trip Time Estimation c 2005–2008 Antonio Carzaniga
  • 402. Round-Trip Time Estimation RTT is measured using ACKs ◮ only for packets transmitted once Given a single sample S at any given time Exponential weighted moving average (EWMA) ′ RTT = (1 − α )RTT + α S c 2005–2008 Antonio Carzaniga
  • 403. Round-Trip Time Estimation RTT is measured using ACKs ◮ only for packets transmitted once Given a single sample S at any given time Exponential weighted moving average (EWMA) ′ RTT = (1 − α )RTT + α S ◮ RFC 2988 recommends α = 0.125 c 2005–2008 Antonio Carzaniga
  • 404. Round-Trip Time Estimation RTT is measured using ACKs ◮ only for packets transmitted once Given a single sample S at any given time Exponential weighted moving average (EWMA) ′ RTT = (1 − α )RTT + α S ◮ RFC 2988 recommends α = 0.125 TCP also measures the variability of RTT ′ ′ DevRTT = (1 − β)DevRTT + β|RTT − S | c 2005–2008 Antonio Carzaniga
  • 405. Round-Trip Time Estimation RTT is measured using ACKs ◮ only for packets transmitted once Given a single sample S at any given time Exponential weighted moving average (EWMA) ′ RTT = (1 − α )RTT + α S ◮ RFC 2988 recommends α = 0.125 TCP also measures the variability of RTT ′ ′ DevRTT = (1 − β)DevRTT + β|RTT − S | ◮ RFC 2988 recommends β = 0.25 c 2005–2008 Antonio Carzaniga
  • 406. Timeout Value c 2005–2008 Antonio Carzaniga
  • 407. Timeout Value The timeout interval T must be larger than the RTT ◮ so as to avoid unnecessary retransmission However, T should not be too far from RTT ◮ so as to detect (and retransmit) lost segments as quickly as possible c 2005–2008 Antonio Carzaniga
  • 408. Timeout Value The timeout interval T must be larger than the RTT ◮ so as to avoid unnecessary retransmission However, T should not be too far from RTT ◮ so as to detect (and retransmit) lost segments as quickly as possible TCP sets its timeouts using the estimated RTT (RTT ) and the variability estimate DevRTT : T = RTT + 4DevRTT c 2005–2008 Antonio Carzaniga
  • 409. Reliable Data Transfer (Sender) A simplified TCP sender r send(data) if (timer not running) start timer() u send([data,next seq num]) next seq num ← next seq num + length(data) c 2005–2008 Antonio Carzaniga
  • 410. Reliable Data Transfer (Sender) A simplified TCP sender r send(data) if (timer not running) start timer() u send([data,next seq num]) next seq num ← next seq num + length(data) timeout u send(pending segment with smallest sequence number) start timer() c 2005–2008 Antonio Carzaniga
  • 411. Reliable Data Transfer (Sender) A simplified TCP sender r send(data) if (timer not running) start timer() u send([data,next seq num]) next seq num ← next seq num + length(data) timeout u send(pending segment with smallest sequence number) start timer() u recv([ACK,y]) if (y > base) base ← y if (∃ pending segments) start timer() else . . . c 2005–2008 Antonio Carzaniga
  • 412. Acknowledgment Generation (Receiver) c 2005–2008 Antonio Carzaniga
  • 413. Acknowledgment Generation (Receiver) Arrival of in-order segment with expected sequence number; all data up to expected sequence number already acknowledged c 2005–2008 Antonio Carzaniga
  • 414. Acknowledgment Generation (Receiver) Arrival of in-order segment with expected sequence number; all data up to expected sequence number already acknowledged ◮ Delayed ACK: wait 500ms for another in-order segment. If that doesn’t happen, send ACK c 2005–2008 Antonio Carzaniga
  • 415. Acknowledgment Generation (Receiver) Arrival of in-order segment with expected sequence number; all data up to expected sequence number already acknowledged ◮ Delayed ACK: wait 500ms for another in-order segment. If that doesn’t happen, send ACK Arrival of in-order segment with expected sequence number. One other in-order segment waiting for ACK (see above) c 2005–2008 Antonio Carzaniga
  • 416. Acknowledgment Generation (Receiver) Arrival of in-order segment with expected sequence number; all data up to expected sequence number already acknowledged ◮ Delayed ACK: wait 500ms for another in-order segment. If that doesn’t happen, send ACK Arrival of in-order segment with expected sequence number. One other in-order segment waiting for ACK (see above) ◮ Cumulative ACK: immediately send cumulative ACK (for both segments) c 2005–2008 Antonio Carzaniga
  • 417. Acknowledgment Generation (Receiver) Arrival of in-order segment with expected sequence number; all data up to expected sequence number already acknowledged ◮ Delayed ACK: wait 500ms for another in-order segment. If that doesn’t happen, send ACK Arrival of in-order segment with expected sequence number. One other in-order segment waiting for ACK (see above) ◮ Cumulative ACK: immediately send cumulative ACK (for both segments) Arrival of out of order segment with higher-than-expected sequence number (gap detected) c 2005–2008 Antonio Carzaniga
  • 418. Acknowledgment Generation (Receiver) Arrival of in-order segment with expected sequence number; all data up to expected sequence number already acknowledged ◮ Delayed ACK: wait 500ms for another in-order segment. If that doesn’t happen, send ACK Arrival of in-order segment with expected sequence number. One other in-order segment waiting for ACK (see above) ◮ Cumulative ACK: immediately send cumulative ACK (for both segments) Arrival of out of order segment with higher-than-expected sequence number (gap detected) ◮ Duplicate ACK: immediately send duplicate ACK c 2005–2008 Antonio Carzaniga
  • 419. Acknowledgment Generation (Receiver) Arrival of in-order segment with expected sequence number; all data up to expected sequence number already acknowledged ◮ Delayed ACK: wait 500ms for another in-order segment. If that doesn’t happen, send ACK Arrival of in-order segment with expected sequence number. One other in-order segment waiting for ACK (see above) ◮ Cumulative ACK: immediately send cumulative ACK (for both segments) Arrival of out of order segment with higher-than-expected sequence number (gap detected) ◮ Duplicate ACK: immediately send duplicate ACK Arrival of segment that (partially or completely) fills a gap in the received data c 2005–2008 Antonio Carzaniga
  • 420. Acknowledgment Generation (Receiver) Arrival of in-order segment with expected sequence number; all data up to expected sequence number already acknowledged ◮ Delayed ACK: wait 500ms for another in-order segment. If that doesn’t happen, send ACK Arrival of in-order segment with expected sequence number. One other in-order segment waiting for ACK (see above) ◮ Cumulative ACK: immediately send cumulative ACK (for both segments) Arrival of out of order segment with higher-than-expected sequence number (gap detected) ◮ Duplicate ACK: immediately send duplicate ACK Arrival of segment that (partially or completely) fills a gap in the received data ◮ Immediate ACK: immediately send ACK if the packet start at the lower end of the gap c 2005–2008 Antonio Carzaniga
  • 421. Reaction to ACKs (Sender) c 2005–2008 Antonio Carzaniga
  • 422. Reaction to ACKs (Sender) u recv([ACK,y]) if (y > base) base ← y if (∃ pending segments) start timer() c 2005–2008 Antonio Carzaniga
  • 423. Reaction to ACKs (Sender) u recv([ACK,y]) if (y > base) base ← y if (∃ pending segments) start timer() else ack counter [y] ← ack counter [y] + 1 if (ack counter [y] = 3) u send(segment with sequence number y) c 2005–2008 Antonio Carzaniga
  • 424. Connection Setup c 2005–2008 Antonio Carzaniga
  • 425. Connection Setup Three-way handshake c 2005–2008 Antonio Carzaniga
  • 426. Connection Setup Three-way handshake client server c 2005–2008 Antonio Carzaniga
  • 427. Connection Setup Three-way handshake client server [SYN, Seq# = cli init seq] c 2005–2008 Antonio Carzaniga
  • 428. Connection Setup Three-way handshake client server [SYN, Seq# = cli init seq] [SYN, ACK , Ack # = cli init seq + 1, Seq# = srv init seq] c 2005–2008 Antonio Carzaniga
  • 429. Connection Setup Three-way handshake client server [SYN, Seq# = cli init seq] [SYN, ACK , Ack # = cli init seq + 1, Seq# = srv init seq] [ACK , Seq# = cli init seq + 1, Ack # = srv init seq + 1] c 2005–2008 Antonio Carzaniga
  • 430. Connection Shutdown “This is it.” “Okay, Bye now.” “Bye.” c 2005–2008 Antonio Carzaniga
  • 431. Connection Shutdown “This is it.” “Okay, Bye now.” “Bye.” client server c 2005–2008 Antonio Carzaniga
  • 432. Connection Shutdown “This is it.” “Okay, Bye now.” “Bye.” client server [FIN] c 2005–2008 Antonio Carzaniga
  • 433. Connection Shutdown “This is it.” “Okay, Bye now.” “Bye.” client server [FIN] [ACK ] c 2005–2008 Antonio Carzaniga
  • 434. Connection Shutdown “This is it.” “Okay, Bye now.” “Bye.” client server [FIN] [ACK ] [FIN] c 2005–2008 Antonio Carzaniga
  • 435. Connection Shutdown “This is it.” “Okay, Bye now.” “Bye.” client server [FIN] [ACK ] [FIN] [ACK ] c 2005–2008 Antonio Carzaniga
  • 436. The TCP State Machine (Client) CLOSED c 2005–2008 Antonio Carzaniga
  • 437. The TCP State Machine (Client) application CLOSED opens connection send SYN SYN SENT c 2005–2008 Antonio Carzaniga
  • 438. The TCP State Machine (Client) application CLOSED opens connection send SYN SYN SENT receive SYN,ACK send ACK ESTABLISHED c 2005–2008 Antonio Carzaniga
  • 439. The TCP State Machine (Client) application CLOSED opens connection send SYN SYN SENT receive SYN,ACK send ACK ESTABLISHED application FIN WAIT 1 closes connection send FIN c 2005–2008 Antonio Carzaniga
  • 440. The TCP State Machine (Client) application CLOSED opens connection send SYN SYN SENT receive SYN,ACK send ACK FIN WAIT 2 ESTABLISHED receive ACK application FIN WAIT 1 closes connection send FIN c 2005–2008 Antonio Carzaniga
  • 441. The TCP State Machine (Client) application CLOSED opens connection send SYN TIME WAIT SYN SENT receive FIN receive SYN,ACK send ACK send ACK FIN WAIT 2 ESTABLISHED receive ACK application FIN WAIT 1 closes connection send FIN c 2005–2008 Antonio Carzaniga
  • 442. The TCP State Machine (Client) application CLOSED opens connection wait 30 seconds send SYN TIME WAIT SYN SENT receive FIN receive SYN,ACK send ACK send ACK FIN WAIT 2 ESTABLISHED receive ACK application FIN WAIT 1 closes connection send FIN c 2005–2008 Antonio Carzaniga
  • 443. The TCP State Machine (Server) CLOSED c 2005–2008 Antonio Carzaniga
  • 444. The TCP State Machine (Server) CLOSED application opens server socket LISTEN c 2005–2008 Antonio Carzaniga
  • 445. The TCP State Machine (Server) CLOSED application opens server socket LISTEN receive SYN send SYN,ACK SYN RCVD c 2005–2008 Antonio Carzaniga
  • 446. The TCP State Machine (Server) CLOSED application opens server socket LISTEN receive SYN send SYN,ACK SYN RCVD receive ACK ESTABLISHED c 2005–2008 Antonio Carzaniga
  • 447. The TCP State Machine (Server) CLOSED application opens server socket LISTEN receive SYN send SYN,ACK CLOSE WAIT SYN RCVD receive FIN receive ACK send ACK ESTABLISHED c 2005–2008 Antonio Carzaniga
  • 448. The TCP State Machine (Server) CLOSED application opens server socket LAST ACK LISTEN receive SYN send FIN send SYN,ACK CLOSE WAIT SYN RCVD receive FIN receive ACK send ACK ESTABLISHED c 2005–2008 Antonio Carzaniga
  • 449. The TCP State Machine (Server) CLOSED application receive ACK opens server socket LAST ACK LISTEN receive SYN send FIN send SYN,ACK CLOSE WAIT SYN RCVD receive FIN receive ACK send ACK ESTABLISHED c 2005–2008 Antonio Carzaniga
  • 450. Part V Congestion Control in TCP c 2005–2008 Antonio Carzaniga
  • 451. Congestion Control (in TCP) c 2005–2008 Antonio Carzaniga
  • 452. Congestion Control (in TCP) Approach: the sender limits its output rate according to the status of the network ◮ the sender output rate becomes (part of) the input rate for the network (λin ) c 2005–2008 Antonio Carzaniga
  • 453. Congestion Control (in TCP) Approach: the sender limits its output rate according to the status of the network ◮ the sender output rate becomes (part of) the input rate for the network (λin ) Issues c 2005–2008 Antonio Carzaniga
  • 454. Congestion Control (in TCP) Approach: the sender limits its output rate according to the status of the network ◮ the sender output rate becomes (part of) the input rate for the network (λin ) Issues ◮ how does the sender “measure” the status of the network? ◮ i.e., how does the sender detect congestion? c 2005–2008 Antonio Carzaniga
  • 455. Congestion Control (in TCP) Approach: the sender limits its output rate according to the status of the network ◮ the sender output rate becomes (part of) the input rate for the network (λin ) Issues ◮ how does the sender “measure” the status of the network? ◮ i.e., how does the sender detect congestion? ◮ how does the sender effectively limit its output rate? c 2005–2008 Antonio Carzaniga
  • 456. Congestion Control (in TCP) Approach: the sender limits its output rate according to the status of the network ◮ the sender output rate becomes (part of) the input rate for the network (λin ) Issues ◮ how does the sender “measure” the status of the network? ◮ i.e., how does the sender detect congestion? ◮ how does the sender effectively limit its output rate? ◮ how should the sender “modulate” its output rate? ◮ i.e., what algorithm should the sender use to decrease or increase its output rate? c 2005–2008 Antonio Carzaniga
  • 457. Detecting Congestion c 2005–2008 Antonio Carzaniga
  • 458. Detecting Congestion If all traffic is correctly acknowledged, then the sender assumes (quite correctly) that there is no congestion c 2005–2008 Antonio Carzaniga
  • 459. Detecting Congestion If all traffic is correctly acknowledged, then the sender assumes (quite correctly) that there is no congestion Congestion means that queue overflow in one or more routers between the sender and the receiver ◮ the visible effect is that some segments are dropped c 2005–2008 Antonio Carzaniga
  • 460. Detecting Congestion If all traffic is correctly acknowledged, then the sender assumes (quite correctly) that there is no congestion Congestion means that queue overflow in one or more routers between the sender and the receiver ◮ the visible effect is that some segments are dropped Therefore the server assumes that the network is congested when it detects a segment loss ◮ time out (i.e., no ACK) ◮ multiple acknowledgements (i.e., NACK) c 2005–2008 Antonio Carzaniga
  • 461. Congestion Window The sender maintains a congestion window W c 2005–2008 Antonio Carzaniga
  • 462. Congestion Window The sender maintains a congestion window W The congestion window limits the amount of bytes that the sender pushes into the network before blocking waiting for acknowledgments c 2005–2008 Antonio Carzaniga
  • 463. Congestion Window The sender maintains a congestion window W The congestion window limits the amount of bytes that the sender pushes into the network before blocking waiting for acknowledgments LastByteSent − LastByteAcked ≤ W where W = min (CongestionWindow , ReceiverWindow) c 2005–2008 Antonio Carzaniga
  • 464. Congestion Window The sender maintains a congestion window W The congestion window limits the amount of bytes that the sender pushes into the network before blocking waiting for acknowledgments LastByteSent − LastByteAcked ≤ W where W = min (CongestionWindow , ReceiverWindow) The resulting maximum output rate is roughly W λ= 2L c 2005–2008 Antonio Carzaniga
  • 465. Congestion Control How does TCP “modulate” its output rate? c 2005–2008 Antonio Carzaniga
  • 466. Congestion Control How does TCP “modulate” its output rate? Additive-increase and multiplicative-decrease c 2005–2008 Antonio Carzaniga
  • 467. Congestion Control How does TCP “modulate” its output rate? Additive-increase and multiplicative-decrease Slow start c 2005–2008 Antonio Carzaniga
  • 468. Congestion Control How does TCP “modulate” its output rate? Additive-increase and multiplicative-decrease Slow start Reaction to timeout events c 2005–2008 Antonio Carzaniga
  • 469. Additive-Increase/Multiplicative-Decrease c 2005–2008 Antonio Carzaniga
  • 470. Additive-Increase/Multiplicative-Decrease How W is reduced: at every loss event, TCP halves the congestion window c 2005–2008 Antonio Carzaniga
  • 471. Additive-Increase/Multiplicative-Decrease How W is reduced: at every loss event, TCP halves the congestion window ◮ e.g., suppose the window size W is currently 20Kb, and a loss is detected ◮ TCP reduces W to 10Kb c 2005–2008 Antonio Carzaniga
  • 472. Additive-Increase/Multiplicative-Decrease How W is reduced: at every loss event, TCP halves the congestion window ◮ e.g., suppose the window size W is currently 20Kb, and a loss is detected ◮ TCP reduces W to 10Kb How W is increased: at every (good) acknowledgment, TCP increments W by 1MSS /W , so as to increase W by MSS every round-trip time 2L. This process is called congestion avoidance c 2005–2008 Antonio Carzaniga
  • 473. Additive-Increase/Multiplicative-Decrease How W is reduced: at every loss event, TCP halves the congestion window ◮ e.g., suppose the window size W is currently 20Kb, and a loss is detected ◮ TCP reduces W to 10Kb How W is increased: at every (good) acknowledgment, TCP increments W by 1MSS /W , so as to increase W by MSS every round-trip time 2L. This process is called congestion avoidance ◮ e.g., suppose W = 14600 and MSS = 1460, then the sender increases W to 16060 after 10 acknowledgments c 2005–2008 Antonio Carzaniga
  • 474. Additive-Increase/Multiplicative-Decrease Window size W over time W Time c 2005–2008 Antonio Carzaniga
  • 475. Slow Start What is the initial value of W ? c 2005–2008 Antonio Carzaniga
  • 476. Slow Start What is the initial value of W ? The initial value of W is MSS, which is quite low for modern networks c 2005–2008 Antonio Carzaniga
  • 477. Slow Start What is the initial value of W ? The initial value of W is MSS, which is quite low for modern networks In order to get quickly to a good throughput level, TCP increases its sending rate exponentially for its first growth phase c 2005–2008 Antonio Carzaniga
  • 478. Slow Start What is the initial value of W ? The initial value of W is MSS, which is quite low for modern networks In order to get quickly to a good throughput level, TCP increases its sending rate exponentially for its first growth phase After experiencing the first loss, TCP cuts W in half and proceeds with its linear push c 2005–2008 Antonio Carzaniga
  • 479. Slow Start What is the initial value of W ? The initial value of W is MSS, which is quite low for modern networks In order to get quickly to a good throughput level, TCP increases its sending rate exponentially for its first growth phase After experiencing the first loss, TCP cuts W in half and proceeds with its linear push This process is called slow start, because of the small initial value of W c 2005–2008 Antonio Carzaniga
  • 480. Timeouts vs. NACKs As we know, three duplicate ACKs are interpreted as a NACK c 2005–2008 Antonio Carzaniga
  • 481. Timeouts vs. NACKs As we know, three duplicate ACKs are interpreted as a NACK Both timeouts and NACKs signal a loss, but they say different things about the status of the network c 2005–2008 Antonio Carzaniga
  • 482. Timeouts vs. NACKs As we know, three duplicate ACKs are interpreted as a NACK Both timeouts and NACKs signal a loss, but they say different things about the status of the network A timeout indicates congestion c 2005–2008 Antonio Carzaniga
  • 483. Timeouts vs. NACKs As we know, three duplicate ACKs are interpreted as a NACK Both timeouts and NACKs signal a loss, but they say different things about the status of the network A timeout indicates congestion Three (duplicate) ACKs suggest that the network is still able to deliver segments along that path c 2005–2008 Antonio Carzaniga
  • 484. Timeouts vs. NACKs As we know, three duplicate ACKs are interpreted as a NACK Both timeouts and NACKs signal a loss, but they say different things about the status of the network A timeout indicates congestion Three (duplicate) ACKs suggest that the network is still able to deliver segments along that path So, TCP reacts differently to a timeout and to a triple duplicate ACKs c 2005–2008 Antonio Carzaniga
  • 485. Timeouts vs. NACKs Assuming the current window size is W = W c 2005–2008 Antonio Carzaniga
  • 486. Timeouts vs. NACKs Assuming the current window size is W = W Timeout ◮ go back to W = MSS ◮ run slow start until W reaches W /2 ◮ then proceed with congestion avoidance c 2005–2008 Antonio Carzaniga
  • 487. Timeouts vs. NACKs Assuming the current window size is W = W Timeout ◮ go back to W = MSS ◮ run slow start until W reaches W /2 ◮ then proceed with congestion avoidance NACK ◮ cut W in half: W = W /2 ◮ run congestion avoidance, ramping up W linearly ◮ This is called fast recovery c 2005–2008 Antonio Carzaniga
  • 488. Sender Behavior W Time c 2005–2008 Antonio Carzaniga
  • 489. Sender Behavior W MSS Time c 2005–2008 Antonio Carzaniga
  • 490. Sender Behavior W NACK MSS Time c 2005–2008 Antonio Carzaniga
  • 491. Sender Behavior W NACK MSS Time c 2005–2008 Antonio Carzaniga
  • 492. Sender Behavior timeout W NACK MSS Time c 2005–2008 Antonio Carzaniga
  • 493. Sender Behavior timeout W NACK MSS Time c 2005–2008 Antonio Carzaniga
  • 494. Sender Behavior timeout W NACK MSS Time c 2005–2008 Antonio Carzaniga
  • 495. Sender Behavior timeout W NACK MSS Time c 2005–2008 Antonio Carzaniga
  • 496. Sender Behavior NACK timeout W NACK MSS Time c 2005–2008 Antonio Carzaniga
  • 497. Sender Behavior NACK timeout NACK W NACK MSS Time c 2005–2008 Antonio Carzaniga
  • 498. Sender Behavior NACK timeout NACK W NACK MSS Time c 2005–2008 Antonio Carzaniga
  • 499. Sender Behavior NACK timeout NACK W NACK MSS Time c 2005–2008 Antonio Carzaniga
  • 500. Sender Behavior SS=slow start CA=congestion avoidance SS CA SS CA CA CA NACK timeout NACK W NACK MSS Time c 2005–2008 Antonio Carzaniga

×