View Carlson Presentation Part 3

  • 274 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
274
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
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
  • * These are the values we are currently we are planning on using, but this is not set in stone.

Transcript

  • 1. The Performance Bottleneck Application, Computer, or Network Richard Carlson Internet2 Part 3
  • 2. Outline
    • Why there is a problem
    • What can be done to find/fix problems
    • Tools you can use
    • Ramblings on what’s next
  • 3. Active Measurement Tools
    • Tools that inject packets into the network to measure some value
      • Available Bandwidth
      • Delay/Jitter
      • Loss
    • Requires bi-directional traffic or synchronized hosts
  • 4. Passive Measurement Tools
    • Tools that monitor existing traffic on the network and extract some information
      • Bandwidth used
      • Jitter
      • Loss rate
    • May generate some privacy and/or security concerns
  • 5. Tools, Tools, Tools
    • Ping
    • Traceroute
    • Iperf
    • Tcpdump
    • Tcptrace
    • BWCTL
    • NDT
    • OWAMP
    • AMP
    • Advisor
    • Thrulay
    • Web100
    • MonaLisa
    • pathchar
    • NPAD
    • Pathdiag
    • Surveyor
    • Ethereal
    • CoralReef
    • MRTG
    • Skitter
    • Cflowd
    • Cricket
    • Net100
  • 6. Network Diagnostic Tool (NDT)
    • Measure performance to users desktop
    • Identify real problems for real users
      • Network infrastructure is the problem
      • Host tuning issues are the problem
    • Make tool simple to use and understand
    • Make tool useful for users and network administrators
  • 7.
    • 10 Mbps NIC
      • Throughput 6.8/6.7 mbps send/receive
      • RTT 20 ms
      • Retransmission/Timeouts 25/3
    • 100 Mbps NIC
      • Throughput 84/86 mbps send/receive
      • RTT 10 ms
      • Retransmission/Timeouts 0/0
    Different Host, same switch port
  • 8. Web100 Project
    • Joint PSC/NCAR project funded by NSF
    • ‘First step’ to gather TCP data
      • Kernel Instrument Set (KIS)
    • Developed patches Linux kernel
    • Geared toward wide area network performance
    • Future steps will automate tuning to improve application performance
  • 9. NDT’s Web100 Based Approach
    • Simple bi-directional test to gather E2E data
    • Gather multiple data variables (a breadth of measurements)
    • Compare measured performance to analytical values
    • Translate network values into plain text messages
    • Geared toward campus area network
  • 10. SC’04 Real Life Example
    • Booth having trouble getting application to run from Amsterdam to Pittsburgh
    • Tests between remote SGI and local PC showed throughput limited to < 20 Mbps
    • Assumption is: PC buffers too small
    • Question: How do we set WinXP send/receive buffer
  • 11. SC’04 Determine WinXP info http://www.dslreports.com/drtcp
  • 12. SC’04 Confirm PC settings
    • DrTCP reported 16 MB buffers, but test program still slow, Q: How to confirm?
    • Run test to SC NDT server (PC has Fast Ethernet Connection)
      • Client-to-Server: 90 Mbps
      • Server-to-Client: 95 Mbps
      • PC Send/Recv Buffer size: 16 Mbytes (wscale 8)
      • NDT Send/Recv Buffer Size: 8 Mbytes (wscale 7)
      • Reported TCP RTT: 46.2 msec
        • approximately 600 Kbytes of data in TCP buffer
      • Min buffer size / RTT: 1.3 Gbps
  • 13. SC’04 Local PC Configured OK
    • No problem found
    • Able to run at line rate
    • Confirmed that PC’s TCP buffers were set correctly
  • 14. SC’04 Remote SGI
    • Run test from remote SGI to SC show floor (SGI is Gigabit Ethernet connected) .
      • Client-to-Server: 17 Mbps
      • Server-to-Client: 16 Mbps
      • SGI Send/Recv Buffer size: 256 Kbytes (wscale 3)
      • NDT Send/Recv Buffer Size: 8 Mbytes (wscale 7)
      • Reported RTT: 106.7 msec
      • Min Buffer size / RTT: 19 Mbps
  • 15. SC’04 Remote SGI Results
    • Needed to download and compile command line client
    • SGI TCP buffer is too small to fill transatlantic pipe (19 Mbps max)
    • User reluctant to make changes to SGI network interface from SC show floor
    • NDT client tool allows application to change buffer (setsockopt() function call)
  • 16. SC’04 Remote SGI (tuned)
    • Re-run test from remote SGI to SC show floor.
      • Client-to-Server: 107 Mbps
      • Server-to-Client: 109 Mbps
      • SGI Send/Recv Buffer size: 2 Mbytes (wscale 5)
      • NDT Send/Recv Buffer Size: 8 Mbytes (wscale 7)
      • Reported RTT: 104 msec
      • Min Buffer size / RTT: 153.8 Mbps
  • 17. SC’04 Debugging Results
    • Team spent over 1 hour looking at Win XP config, trying to verify Buffer size
    • Single NDT test verified this in under 30 seconds
    • 10 minutes to download and install NDT client on SGI
    • 15 minutes to discuss options and run client test with set buffer option
  • 18. SC’04 Debugging Results
    • 8 Minutes to find SGI limits and determine maximum allowable buffer setting (2 MB)
    • Total time 34 minutes to verify problem was with remote SGIs’ TCP send/receive buffer size
    • Network path verified but Application still performed poorly until it was also tuned
  • 19. NDT Benefits
    • End-user based view of network
    • Can be used to identify performance bottlenecks (could be host problem)
    • Provides some ‘hard evidence’ to users and network administrators to reduce finger pointing
    • Doesn’t rely on historical data
  • 20. Web Based Performance tool
    • Operates on Any client with a Java enabled Web browser
    • What it can do
      • Positively state if Sender, Receiver, or Network is operating properly
      • Provide accurate application tuning info
      • Suggest changes to improve performance
  • 21. Web base Performance tool
    • What it can’t do
      • Tell you where in the network the problem is
      • Tell you how other servers perform
      • Tell you how other clients will perform
  • 22. NDT methodology
    • Identify specific problem(s) that affect end users
    • Analyze problem to determine ‘Network Signature’ for this problem
    • Provide testing tool to automate detection process
  • 23. Duplex Mismatch Detection
    • Developing analytical model to describe how network operates (no prior art?)
    • Expanding model to describe UDP and TCP flows
    • Test models in LAN, MAN, and WAN environments
    • NIH/NLM grant funding
  • 24. Test environment
    • Receiver is put is various states
      • Switch = full & Host = full or half
      • Switch = half & Host = full or half
    Switch NDT Srv Source 100 Mbps Full Duplex NDT Clt Receiver 100 Mbps Mismatch
  • 25. Ethernet transmission strategy
    • Half Duplex
      • Use carrier sense signal to determine if link in use
      • If not, send frame at head of queue
      • Else, wait for frame to end and send frame
      • Use collision detection signal to determine if other station also sends
    • Full Duplex
      • Send packet at head of queue
      • Disable carrier sense
      • Disable collision detection
  • 26. Analytical Loss-Model Loss vs Transmission rate
  • 27. Analytical Loss-Model Low speed loss vs send rate
  • 28. UDP Loss-Model Sender view – normal operation
  • 29. UDP Loss-Model Sender view – lost data pkts
  • 30. UDP Loss-Model Sender view – lost acks
  • 31. TCP Operation on LAN
    • Observed behavior depends on direction of TCP flow and direction of mismatch
      • Data and ACK packets delivered
      • Data packets lost and ACKs delayed
      • ACKs packets lost and Data delayed
    • Losing ACKs has bigger effect than losing Data packets
    • Web100 details are only available when NDT server is source and client is sink
  • 32. Four Cases of Duplex Setting FD-FD FD-HD HD-FD HD-HD
  • 33. Duplex Mismatch Switch is Full & Host is Half
  • 34. Tentative Mismatch Detection
    • Full to Half mismatch detection
      • Large percentage of duplicate ACKs
      • Connection spends majority of the time in CwndLimited state
      • Asymmetric throughput
        • opposite direction is less
  • 35. Duplex Mismatch Switch is Half & Host is Full
  • 36. Tentative Mismatch Detection
    • Half to Full mismatch detection
      • Large number of timeouts causes long idle time (RTO x timeout value)
      • Connection spends majority of the time in CwndLimited state
      • Asymmetric throughput
        • opposite direction is greater
  • 37. Bottleneck Link Detection
    • What is the slowest link in the end-2-end path?
      • Monitors packet arrival times using libpacp routine
      • Use TCP dynamics to create packet pairs
      • Quantize results into link type bins (no fractional or bonded links)
    • Cisco URP grant work
  • 38. Normal congestion detection
    • Shared network infrastructures will cause periodic congestion episodes
      • Detect/report when TCP throughput is limited by cross traffic
      • Detect/report when TCP throughput is limited by own traffic
  • 39. Faulty Hardware/Link Detection
    • Detect non-congestive loss due to
      • Faulty NIC/switch interface
      • Bad Cat-5 cable
      • Dirty optical connector
    • Preliminary works shows that it is possible to distinguish between congestive and non-congestive loss
  • 40. Full/Half Link Duplex setting
    • Detect half-duplex link in E2E path
      • Identify when throughput is limited by half-duplex operations
    • Preliminary work shows detection possible when link transitions between blocking states
  • 41. Additional Functions and Features
    • Provide basic tuning information
    • Basic Features
      • Basic configuration file
      • FIFO scheduling of tests
      • Simple server discovery protocol
      • Federation mode support
      • Command line client support
    • Created sourceforge.net project page
  • 42. Internet2 piPEs Project
    • Develop E2E measurement infrastructure capable of finding network problems
    • Tools include
      • BWCTL: Bandwidth Control wrapper for NLANR Iperf
      • OWAMP: One-Way Active Measurement
      • NDT: Network Diagnostic Tool
  • 43.  
  • 44. BWCTL Design Goals
    • Bandwidth Control Server
    • Wrapper for Dast Iperf tool
    • Performs scheduled tests between 11 peers
    • Supports on-demand tests between peer nodes
  • 45. Architecture
  • 46. Specific difficulties
    • UDP
      • Iperf doesn’t always send at requested rate
      • Iperf sender hangs (likely Linux/iperf interaction – could be due to signal handling of the bwctl level)
      • End of session is difficult to detect, which is problematic for a “scheduled” timeslot
      • Iperf sometimes takes large amounts of time to finish
  • 47. Specific difficulties
    • TCP
      • Large pipe to small pipe
        • Launch a large window
        • Test waits until completion
        • Terminate test to remain within schedule
        •  Sets of incomplete tests to interpret
      • Full mesh presents difficulties for window size selection (and other path specific characteristics)
        • bwctl uses the peer to peer server connection to deduce a “reasonable” window
        • If at all possible path specific parameters need to be dynamically configured
  • 48. Future Possibilities
    • Server-less client side for end hosts
    • Closer integration with test engine (iperf API?)
      • Better error detection
      • Better timing control (begin and end of test is currently a problem)
    • 3-party tests (client not on one of the endpoints)
    • Open source development
  • 49. Availability
    • Beta version currently available
      • www.internet2.edu/bwctl/
    • Mail lists:
    • bwctl-users
    • bwctl-announce
    • https://mail.internet2.edu/wws/lists/engineering
  • 50. OWAMP Design Goals
    • One-Way-Active-Measurement-Protocol
      • Possible due to growing availability of good time sources
      • Wide deployment of “open” servers would allow measurement of one-way delay to become as commonplace as measurement of RTT using ICMP tools such as ping.
      • Current Draft: draft-ietf-ippm-owdp-07.txt
        • Shalunov,Teitelbaum,Karp,Boote,Zekauskas
        • RFC just released
      • Sample implementation under development
        • Alpha code currently available
  • 51. Abilene OWAMP deployment
    • 2 overlapping full meshes (IPv4 & IPv6)
      • 11 measurement nodes = 220 ongoing tests
      • UDP singletons
      • Rate: 10 packets/second*
      • Packetsize: (32 byte payload)*
      • Results are continuously streamed back to “Measurement Portal” for long-term archive and data dissemination (Near real-time)
  • 52. OWAMP Errors
    • Preliminary Findings:
      • Min error estimates look to be in the 55-60 usec range.
      • Serialization Delay: ~5usec x 2
      • Get Timestamp: ~15usec x 2
      • Additional error is:
        • Time from userland “send” to 1 st byte hits the wire
        • Time from kernel has packet to userland “recv” returns
        • Potentially recv process data processing before calling “recv”
  • 53. OWAMP implementation status
    • Sample implementation
    • http://e2epi.internet2.edu/owamp/
      • Alpha Release ver 1.6c:
        • No “policy”
        • No authentication/encryption
        • Tested on FreeBSD & Linux
  • 54. Sample Traceroute Tree map R6 R7 R5 R4 R3 R2 R1 S2 S3 S7 S8 S1 S6 S5 S4
  • 55. Sample Traceroute from S1 to Client Traceroute to Client R5 R4 R1 S1 Rc Rb Ra Client
  • 56. Sample Traceroute Tree map S2 S3 S7 S8 S1 S6 S5 S4 R6 R7 R5 R4 R3 R2 R1 R5 R4 R1 S1 Rc Rb Ra Client
  • 57. Client re-directed to S6 for test Rc Rb Ra Client R5 S6