1 / 12

Bridge Out: Extending RFC 2544 for DCB Devices

Bridge Out: Extending RFC 2544 for DCB Devices. Timmons C. Player David Newman IETF BMWG interim meeting, 30 October 2009. Agenda. World’s shortest DCB intro Limitations of throughput for DCB Limitations of latency for DCB Other problems New metrics for DCB testing. Introducing DCB.

isla
Télécharger la présentation

Bridge Out: Extending RFC 2544 for DCB Devices

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Bridge Out:Extending RFC 2544 for DCB Devices Timmons C. Player David Newman IETF BMWG interim meeting, 30 October 2009

  2. Agenda • World’s shortest DCB intro • Limitations of throughput for DCB • Limitations of latency for DCB • Other problems • New metrics for DCB testing

  3. Introducing DCB • DCB (aka DCE, CEE) converges data, storage onto single network • IEEE 802.1Qbb (aka PFC) adds flow control per VLAN priority • Other DCB mechanisms for: • Capabilities exchange (DCBX) • Congestion notification (802.1Qau) • Shaping (802.1Qaz)

  4. What’s wrong with throughput? • RFC 1242 throughput is fine – for Ethernet • Canonical method: Measure oload with 0 loss, followed by oload with packet loss • Highest zero-drop rate is the throughput rate • This does not work for DCB

  5. What’s wrong with throughput? • Loss should never occur with DCB • Flow control throttles transmitters • Impossible to have success case, then fail case • No distinction between iload and oload • Device that forwards 0 packets could have “line-rate throughput” in DCB context • No distinction among traffic classes • Different classes may (and probably will) have different maximum forwarding rates

  6. What’s wrong with latency? • RFC 2544, section 26.2, requires measurement at throughput rate • Oops: There is no throughput rate • RFC 1242 uses different measurements for store-and-forward, bit-forwarding • Oops: DCB devices may alternate modes • RFC 2544 does not measure per class

  7. What else can go wrong? • 2544/2889 tests use “lock step” pattern • 1 -> [2,3,4]; 2 -> [3,4,1]; 3-> [4,1,2]; etc. • Very regular packet departure intervals

  8. What else can go wrong? • DCB devices quickly go out of lock step • Not just per-port but also per-class • Much tougher on schedulers

  9. DCB testing: What’s new • Proposed new work item:http://www.ietf.org/id/draft-player-dcb-benchmarking-00.txt • New metric: Queueput • Measures MOL per classification • Multiple queueputs, one per classification, are possible • Maximum forwarding rate • Same concept as in 2285/2889 • For DCB, more meaningful than throughput • Extended to measure per classification

  10. DCB testing: What’s new • Back-off measures DUT PFC overhead • Conceptually similar to 2544 frame loss test • Offer traffic above queueput rate; then reduce iload until the DUT no longer pauses ingress traffic • Measure per classification

  11. DCB testing: What’s new • Back-to-back • Conceptually similar to back-off in RFCs 1242/2544 • Extended to measure per classification • Other DCB metrics?

  12. Thanks! • timmons.player@spirent.com • dnewman@networktest.com

More Related