doc.: ieee 802.11-00/184 submission slide 1 july, 2000 arun ayyagari, et al microsoft,inc. ieee...

19
July, 2000 doc.: IEEE 802.11-00/184 Arun Ayyagari, et al Microsoft,Inc. Submission Slide 1 IEEE 802.11e IEEE 802.11e QoS Application QoS Application Scenarios Scenarios Arun Ayyagari, Yoram Bernet, Tim Moore, Victoria Arun Ayyagari, Yoram Bernet, Tim Moore, Victoria Poncini Poncini Microsoft Corporation Microsoft Corporation

Upload: roger-brendan-farmer

Post on 14-Jan-2016

216 views

Category:

Documents


3 download

TRANSCRIPT

Page 1: Doc.: IEEE 802.11-00/184 Submission Slide 1 July, 2000 Arun Ayyagari, et al Microsoft,Inc. IEEE 802.11e QoS Application Scenarios Arun Ayyagari, Yoram

July, 2000 doc.: IEEE 802.11-00/184

Arun Ayyagari, et al Microsoft,Inc.Submission Slide 1

IEEE 802.11eIEEE 802.11e QoS Application QoS Application

ScenariosScenariosArun Ayyagari, Yoram Bernet, Tim Moore, Victoria PonciniArun Ayyagari, Yoram Bernet, Tim Moore, Victoria Poncini

Microsoft CorporationMicrosoft Corporation

Page 2: Doc.: IEEE 802.11-00/184 Submission Slide 1 July, 2000 Arun Ayyagari, et al Microsoft,Inc. IEEE 802.11e QoS Application Scenarios Arun Ayyagari, Yoram

July, 2000 doc.: IEEE 802.11-00/184

Arun Ayyagari, et al Microsoft,Inc.Submission Slide 2

Signaling ScenarioSignaling Scenario Quantitative applicationsQuantitative applications

indicate the type of service they needindicate the type of service they need quantify resources at that service levelquantify resources at that service level

Network devices along the routeNetwork devices along the route review requestreview request check for resource availabilitycheck for resource availability may apply policy checkmay apply policy check may install state to recognize flow (RSVP)may install state to recognize flow (RSVP) approve/deny requestapprove/deny request adjust resource availability adjust resource availability

Page 3: Doc.: IEEE 802.11-00/184 Submission Slide 1 July, 2000 Arun Ayyagari, et al Microsoft,Inc. IEEE 802.11e QoS Application Scenarios Arun Ayyagari, Yoram

July, 2000 doc.: IEEE 802.11-00/184

Arun Ayyagari, et al Microsoft,Inc.Submission Slide 3

SBMDirectory

Differentiated Service Network(s)

IEEE 802.11Network

AP

Page 4: Doc.: IEEE 802.11-00/184 Submission Slide 1 July, 2000 Arun Ayyagari, et al Microsoft,Inc. IEEE 802.11e QoS Application Scenarios Arun Ayyagari, Yoram

July, 2000 doc.: IEEE 802.11-00/184

Arun Ayyagari, et al Microsoft,Inc.Submission Slide 4

3. QoS service 3. QoS service provider sends provider sends RSVP PATH RSVP PATH message to message to networknetwork

1. Application 1. Application indicates that it indicates that it is a QoS senderis a QoS sender

TCP/IPTCP/IP

NetCardNetCard

WinSock2 APIWinSock2 API

QoS-aware QoS-aware applicationapplication

2. QoS SP invokes 2. QoS SP invokes non-greedy traffic non-greedy traffic controlcontrol

QoS SPQoS SP

Traffic Control APITraffic Control API

Packet SchedulerPacket Scheduler

MAC SAPMAC SAP

NDIS NDIS

Page 5: Doc.: IEEE 802.11-00/184 Submission Slide 1 July, 2000 Arun Ayyagari, et al Microsoft,Inc. IEEE 802.11e QoS Application Scenarios Arun Ayyagari, Yoram

July, 2000 doc.: IEEE 802.11-00/184

Arun Ayyagari, et al Microsoft,Inc.Submission Slide 5

SBM Directory

4. PATH message arrives at router4. PATH message arrives at router

5. Router applies sender policy check against directory5. Router applies sender policy check against directory

Differentiated Service Network(s)

IEEE 802.11Network

6. Sender approved, PATH forwarded to next router6. Sender approved, PATH forwarded to next router

7. Next router applies sender policy check against directory7. Next router applies sender policy check against directory

8. Sender approved, PATH forwarded to Diff-Serv ingress router8. Sender approved, PATH forwarded to Diff-Serv ingress router

9. Diff-Serv ingress router checks for admissibility against SLA9. Diff-Serv ingress router checks for admissibility against SLA

AP

Page 6: Doc.: IEEE 802.11-00/184 Submission Slide 1 July, 2000 Arun Ayyagari, et al Microsoft,Inc. IEEE 802.11e QoS Application Scenarios Arun Ayyagari, Yoram

July, 2000 doc.: IEEE 802.11-00/184

Arun Ayyagari, et al Microsoft,Inc.Submission Slide 6

SBM Directory

10. Resource request approved, PATH propagated transparently through Diff-Serv 10. Resource request approved, PATH propagated transparently through Diff-Serv networknetwork

11. PATH arrives at campus network ingress router11. PATH arrives at campus network ingress router

Differentiated Service Network(s)

IEEE 802.11Network

12. Router applies sender policy check against directory12. Router applies sender policy check against directory

13. Policy check approved, PATH forwarded to receiving host13. Policy check approved, PATH forwarded to receiving host

AP

Page 7: Doc.: IEEE 802.11-00/184 Submission Slide 1 July, 2000 Arun Ayyagari, et al Microsoft,Inc. IEEE 802.11e QoS Application Scenarios Arun Ayyagari, Yoram

July, 2000 doc.: IEEE 802.11-00/184

Arun Ayyagari, et al Microsoft,Inc.Submission Slide 7

15. Application 15. Application indicates that it indicates that it is a Qos receiveris a Qos receiver

14. PATH message 14. PATH message arrives at QoS SParrives at QoS SP

16. QoS SP sends 16. QoS SP sends RSVP RESV RSVP RESV message message to networkto network

QoS SPQoS SP

TCP/IPTCP/IP

NetCardNetCard

WinSock2 APIWinSock2 API

QoS-aware QoS-aware applicationapplication

NDISNDIS

Packet SchedulerPacket Scheduler

MAC SAPMAC SAP

Page 8: Doc.: IEEE 802.11-00/184 Submission Slide 1 July, 2000 Arun Ayyagari, et al Microsoft,Inc. IEEE 802.11e QoS Application Scenarios Arun Ayyagari, Yoram

July, 2000 doc.: IEEE 802.11-00/184

Arun Ayyagari, et al Microsoft,Inc.Submission Slide 8

SBMDirectory

Differentiated Service Network(s)

IEEE 802.11Network

17. RESV message reaches first router17. RESV message reaches first router

18. Router checks resource availability and admits resource request18. Router checks resource availability and admits resource request

20. Admitted RESV is forwarded to next router20. Admitted RESV is forwarded to next router

21. Router checks resource availability and applies receiver policy check against directory21. Router checks resource availability and applies receiver policy check against directory

22. Checks approved, RESV forwarded22. Checks approved, RESV forwarded

AP

Page 9: Doc.: IEEE 802.11-00/184 Submission Slide 1 July, 2000 Arun Ayyagari, et al Microsoft,Inc. IEEE 802.11e QoS Application Scenarios Arun Ayyagari, Yoram

July, 2000 doc.: IEEE 802.11-00/184

Arun Ayyagari, et al Microsoft,Inc.Submission Slide 9

SBMDirectory

Differentiated Service Network(s)

IEEE 802.11Network

23. RESV message forwarded transparently through Diff-Serv23. RESV message forwarded transparently through Diff-Serv

24. Receiver policy check may be applied at Diff-Serv edge 24. Receiver policy check may be applied at Diff-Serv edge

25. RESV is forwarded to campus egress router25. RESV is forwarded to campus egress router

26. Router applies internal resource check and receiver policy check against directory26. Router applies internal resource check and receiver policy check against directory

27. Checks approved, RESV forwarded27. Checks approved, RESV forwarded

AP

Page 10: Doc.: IEEE 802.11-00/184 Submission Slide 1 July, 2000 Arun Ayyagari, et al Microsoft,Inc. IEEE 802.11e QoS Application Scenarios Arun Ayyagari, Yoram

July, 2000 doc.: IEEE 802.11-00/184

Arun Ayyagari, et al Microsoft,Inc.Submission Slide 10

SBM Directory

Differentiated Service Network(s)

IEEE 802.11Network

28. Next router applies internal resource check and receiver policy check against directory28. Next router applies internal resource check and receiver policy check against directory

29. Checks approved, RESV forwarded to SBM 29. Checks approved, RESV forwarded to SBM

30.30. SBM applies resource check on behalf of AP (Note: SBM could be co-located with AP)SBM applies resource check on behalf of AP (Note: SBM could be co-located with AP)

31. SBM approves resource check, RESV continues back to sender31. SBM approves resource check, RESV continues back to sender

AP

Page 11: Doc.: IEEE 802.11-00/184 Submission Slide 1 July, 2000 Arun Ayyagari, et al Microsoft,Inc. IEEE 802.11e QoS Application Scenarios Arun Ayyagari, Yoram

July, 2000 doc.: IEEE 802.11-00/184

Arun Ayyagari, et al Microsoft,Inc.Submission Slide 11

32. RESV message 32. RESV message arrives from network, arrives from network, indicating successful indicating successful admission controladmission control

33. QoS SP indicates 33. QoS SP indicates successful admission successful admission control to applicationcontrol to applicationTCP/IPTCP/IP

WinSock2 APIWinSock2 API

QoS-aware QoS-aware applicationapplication

34. QoS SP invokes 34. QoS SP invokes greedy traffic control greedy traffic control (marking)(marking)

Traffic Control APITraffic Control API

QoS SPQoS SP

NetCardNetCard

35. Transmitted data 35. Transmitted data is marked high is marked high prioritypriority

Packet SchedulerPacket Scheduler

MAC SAPMAC SAP

NDIS NDIS

Packets tagged with Packets tagged with DSCP by RSVPDSCP by RSVP

Page 12: Doc.: IEEE 802.11-00/184 Submission Slide 1 July, 2000 Arun Ayyagari, et al Microsoft,Inc. IEEE 802.11e QoS Application Scenarios Arun Ayyagari, Yoram

July, 2000 doc.: IEEE 802.11-00/184

Arun Ayyagari, et al Microsoft,Inc.Submission Slide 12Differentiated Service Network(s)

IEEE 802.11Network

Packets passing through AP and switch are allotted resources based on 802.1p marking Packets passing through AP and switch are allotted resources based on 802.1p marking

Packets passing through RSVP capable routers are allotted resources based on classification Packets passing through RSVP capable routers are allotted resources based on classification information conveyed in RSVP messages information conveyed in RSVP messages

Packets passing through Diff-Serv network are allotted resources based on DS-field (TOS) Packets passing through Diff-Serv network are allotted resources based on DS-field (TOS) marking marking

AP/SBM

Page 13: Doc.: IEEE 802.11-00/184 Submission Slide 1 July, 2000 Arun Ayyagari, et al Microsoft,Inc. IEEE 802.11e QoS Application Scenarios Arun Ayyagari, Yoram

July, 2000 doc.: IEEE 802.11-00/184

Arun Ayyagari, et al Microsoft,Inc.Submission Slide 13

What to ExpectWhat to Expect Non-greedy traffic control (e.g. shaping) Non-greedy traffic control (e.g. shaping)

always applied immediatelyalways applied immediately Greedy traffic control (priority boost) Greedy traffic control (priority boost)

applied after network approvesapplied after network approves unless overridden by network administratorunless overridden by network administrator best effort until thenbest effort until then

Application will be notified upon network Application will be notified upon network approval/denialapproval/denial

Denial of reservation does not prohibit Denial of reservation does not prohibit sending, just means no QoS assurancesending, just means no QoS assurance

Page 14: Doc.: IEEE 802.11-00/184 Submission Slide 1 July, 2000 Arun Ayyagari, et al Microsoft,Inc. IEEE 802.11e QoS Application Scenarios Arun Ayyagari, Yoram

July, 2000 doc.: IEEE 802.11-00/184

Arun Ayyagari, et al Microsoft,Inc.Submission Slide 14

Service TypesService Types Best effort = DCSP of 0Best effort = DCSP of 0

Default flowDefault flow Not typically requested by applicationsNot typically requested by applications Low priorityLow priority Typically borrows from other flowsTypically borrows from other flows

Controlled load = DCSP of 5 or 3Controlled load = DCSP of 5 or 3 Gets service equivalent to lightly loaded networkGets service equivalent to lightly loaded network Medium priorityMedium priority

Guaranteed service = DCSP of 5 or 3Guaranteed service = DCSP of 5 or 3 Guaranteed delay boundsGuaranteed delay bounds Highest priorityHighest priority

Page 15: Doc.: IEEE 802.11-00/184 Submission Slide 1 July, 2000 Arun Ayyagari, et al Microsoft,Inc. IEEE 802.11e QoS Application Scenarios Arun Ayyagari, Yoram

July, 2000 doc.: IEEE 802.11-00/184

Arun Ayyagari, et al Microsoft,Inc.Submission Slide 15

RSVP Token Bucket ParametersRSVP Token Bucket Parameters Token bucket specification (TSpec)Token bucket specification (TSpec)

Token rateToken rate Bytes of IP datagrams per second (1 bytes per second to 40 terabytes per Bytes of IP datagrams per second (1 bytes per second to 40 terabytes per

second)second) Bucket depthBucket depth

Bytes (1 byte to 250 gigabytes)Bytes (1 byte to 250 gigabytes) Peak traffic ratePeak traffic rate

Bytes of IP datagrams per second (1 byte per second to 40 terabytes per Bytes of IP datagrams per second (1 byte per second to 40 terabytes per second)second)

Minimum policed unitMinimum policed unit BytesBytes

Maximum packet sizeMaximum packet size BytesBytes

Resource specification (RSpec) – for guaranteed serviceResource specification (RSpec) – for guaranteed service Required service rateRequired service rate

Greater than or equal to token rateGreater than or equal to token rate Slack termSlack term

Difference between desired delay and the delay obtained using the required Difference between desired delay and the delay obtained using the required service rateservice rate

Page 16: Doc.: IEEE 802.11-00/184 Submission Slide 1 July, 2000 Arun Ayyagari, et al Microsoft,Inc. IEEE 802.11e QoS Application Scenarios Arun Ayyagari, Yoram

July, 2000 doc.: IEEE 802.11-00/184

Arun Ayyagari, et al Microsoft,Inc.Submission Slide 16

QoS for Qualitative ApplicationsQoS for Qualitative Applications

Page 17: Doc.: IEEE 802.11-00/184 Submission Slide 1 July, 2000 Arun Ayyagari, et al Microsoft,Inc. IEEE 802.11e QoS Application Scenarios Arun Ayyagari, Yoram

July, 2000 doc.: IEEE 802.11-00/184

Arun Ayyagari, et al Microsoft,Inc.Submission Slide 17

For qualitative QoS, traffic is marked for For qualitative QoS, traffic is marked for high priority without negotiating with high priority without negotiating with the network = DCSP of 5 or 3the network = DCSP of 5 or 3 no a-priori knowledge of traffic routesno a-priori knowledge of traffic routes no knowledge of traffic volumeno knowledge of traffic volume

Example, use IEEE 802.1p markingExample, use IEEE 802.1p marking

Page 18: Doc.: IEEE 802.11-00/184 Submission Slide 1 July, 2000 Arun Ayyagari, et al Microsoft,Inc. IEEE 802.11e QoS Application Scenarios Arun Ayyagari, Yoram

July, 2000 doc.: IEEE 802.11-00/184

Arun Ayyagari, et al Microsoft,Inc.Submission Slide 18

Network management applications call Network management applications call TC API = DCSP of 7TC API = DCSP of 7 configure priority, shaping on behalf of configure priority, shaping on behalf of

applicationapplication classification according to port, address, classification according to port, address,

protocolprotocol

open loop - must be based on estimates of open loop - must be based on estimates of traffic patterns, statistics, and heuristicstraffic patterns, statistics, and heuristics

Example, use average rate, peak rate, Example, use average rate, peak rate, and burst sizeand burst size

Page 19: Doc.: IEEE 802.11-00/184 Submission Slide 1 July, 2000 Arun Ayyagari, et al Microsoft,Inc. IEEE 802.11e QoS Application Scenarios Arun Ayyagari, Yoram

July, 2000 doc.: IEEE 802.11-00/184

Arun Ayyagari, et al Microsoft,Inc.Submission Slide 19

TCP/IPTCP/IP

NetCardNetCard

WinSock2 APIWinSock2 API

QoS-aware QoS-aware applicationapplication

QoS SPQoS SP

Traffic Control APITraffic Control API

Packet Scheduler Packet Scheduler

MAC SAPMAC SAP

NDIS NDIS TCP/IPTCP/IP

NetCardNetCard

QoS-aware QoS-aware applicationapplication

Packets tagged with Packets tagged with DSCP by RSVPDSCP by RSVP

Packets tagged Packets tagged with DSCP by with DSCP by Application can be Application can be 802.1p or BE802.1p or BE

RSVP Signaled Quantitative and Qualitative: Guaranteed or Controlled Load or BE

Non-RSVP Signaled Qualitative: 802.1p or BE