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,138

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,138
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>

×