Your SlideShare is downloading. ×
0
herunterladen
herunterladen
herunterladen
herunterladen
herunterladen
herunterladen
herunterladen
herunterladen
herunterladen
herunterladen
herunterladen
herunterladen
herunterladen
herunterladen
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

herunterladen

2,139

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
2,139
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
2
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. QoS research in a complicated world Christian Huitema Architect Windows Networking & Communications Microsoft Corporation
  2. The state of research ? <ul><li>We need QoS for VoIP, video on demand, etc. </li></ul><ul><li>To implement QoS, we need queuing models, signaling protocols, QoS contracts, etc. </li></ul><ul><li>And I get to do tons of maths and publish papers. </li></ul>
  3. The contrarian's view <ul><li>Look at the real network! </li></ul><ul><li>We don’t really need QoS for VoIP, we need bandwidth for video on demand, etc. </li></ul><ul><li>QoS signaling is dead. </li></ul><ul><li>Maths are nice, use them for adaptivity. </li></ul>
  4. Myth : QoS provides better service <ul><li>Myth: </li></ul><ul><ul><li>In a QoS enabled network, you get more bandwidth, less delays </li></ul></ul><ul><li>Reality: </li></ul><ul><ul><li>QoS = access control. </li></ul></ul><ul><ul><li>You can only provide better service to some if you exclude others. </li></ul></ul><ul><li>Deployment issue: </li></ul><ul><ul><li>Only develop an application, if there is enough bandwidth “in most places” </li></ul></ul>
  5. Myth: Applications will require QoS <ul><li>Myth: </li></ul><ul><ul><li>Applications will use a QoS API, because that will give better service. </li></ul></ul><ul><li>Reality </li></ul><ul><ul><li>As long as QoS is not ubiquitous, applications must be adaptive. </li></ul></ul><ul><li>Deployment issue </li></ul><ul><ul><li>Since applications don’t require it, little incentive to upgrade the network. </li></ul></ul><ul><ul><li>Little incentive to maintain the API </li></ul></ul>
  6. Myth: congestion occurs in the network <ul><li>Myth: </li></ul><ul><ul><li>There are bottlenecks in the network, each hop adds delays </li></ul></ul><ul><li>Reality: </li></ul><ul><ul><li>Look at Global Crossing, Qwest, Worldcom </li></ul></ul><ul><ul><li>Price of Mbps divided by 6 in 2 years </li></ul></ul><ul><ul><li>Congestion occurs mostly at the edges. </li></ul></ul><ul><li>Deployment issue: </li></ul><ul><ul><li>Operators of large networks don’t perceive any benefit to QoS, just costs. </li></ul></ul>
  7. Myth: QoS mechanism provide quality <ul><li>Myth: </li></ul><ul><ul><li>We can use QoS mechanisms to protect users from network issues </li></ul></ul><ul><li>Reality: </li></ul><ul><ul><li>How exactly do we use QoS to protect a web server against a denial of service attack? </li></ul></ul><ul><li>Deployment issue: </li></ul><ul><ul><li>Making the network more robust requires “last mile” solutions. </li></ul></ul>
  8. Myth: eventually, QoS everywhere <ul><li>Myth: </li></ul><ul><ul><li>Eventually, all routers will provide QoS </li></ul></ul><ul><li>Reality: </li></ul><ul><ul><li>“ Wireless guarantee” is an oxymoron </li></ul></ul><ul><li>Deployment issue: </li></ul><ul><ul><li>A broken QoS promise will break the application. </li></ul></ul><ul><ul><li>If you cannot have QoS everywhere, the application must be adaptive </li></ul></ul>
  9. A short summary The difference between theory and practice is even larger in practice than in theory
  10. Three QoS research suggestions <ul><li>Apply local solutions to local problems </li></ul><ul><li>Get more data </li></ul><ul><li>If you don’t have guarantee, adapt! </li></ul>
  11. Suggestion: research edge solutions <ul><li>Backbone = large, edge = small </li></ul><ul><ul><li>The law of big numbers does not apply to small numbers </li></ul></ul><ul><li>Edge = degrees of liberty for innovation </li></ul><ul><ul><li>MAC layer for wireless (802.1p ?) </li></ul></ul><ul><ul><li>Cooperation between local players </li></ul></ul><ul><ul><li>Receive side enforcement </li></ul></ul><ul><ul><li>First router solutions… </li></ul></ul><ul><li>Liberty => research playground </li></ul>
  12. Suggestion: get as much data as we can! <ul><li>Understand delays and losses </li></ul><ul><ul><li>In the network, at the edges </li></ul></ul><ul><ul><li>What is the distribution? </li></ul></ul><ul><ul><li>What are the causes? </li></ul></ul><ul><li>Fix the obvious bugs! </li></ul><ul><ul><li>E.g. router hiccups, bad hardware </li></ul></ul><ul><li>Repeat the measurements </li></ul><ul><ul><li>Don’t settle for yesteryear data. </li></ul></ul><ul><ul><li>History matters! </li></ul></ul><ul><ul><li>Praise the XVI century astronomers! </li></ul></ul>
  13. Suggestion: research adaptation models <ul><li>Today’s model are very crude </li></ul><ul><ul><li>The 1988 Internet </li></ul></ul><ul><ul><li>6 nodes NS simulations… </li></ul></ul><ul><li>TCP slow-start is probably wrong </li></ul><ul><li>If we learn about the network, we can design better adaptation models </li></ul>APP APP Need the right black box model
  14. A short summary <ul><li>Success is, finding something your professors don’t know </li></ul><ul><li>Even better, prove them wrong </li></ul><ul><li>Learn how the Internet really behaves, </li></ul><ul><li>Find where the old hypotheses are wrong, </li></ul><ul><li>Build on it! </li></ul>

×