Experiences Configuring AMI and Demos

1
Experiences Configuring AMI and Demos

• Matt Zekauskas, matt_at_internet2.edu
• Internet2 Spring MM pipefitters

2
Goals

• So far, configuring
• Abilene
• HI Joint Techs Hawaii
• CERN GNEW 2004
• ITECs (to some extent)
• What was hard?
• Did we learn anything?

3
Caveat

• Were still configuring, still learning
• Its really too early to do a true lessons
  learned talk

4
Abilene

• Mostly mundane
• Experiences with stacks, keep experimenting test
  and verify
• Hardware. Drivers. Reordering.
• Operating System issues FreeBSD
• netbsd rumored best of all 4.xGbps commodity
  ca.us pop to .se
• Wish for Web100 more later
• 48vdc COTS gt back a generation

5
HI

• Actually found a performance problem
• but it was a known performance problem
• In addition iperf not meant to be scheduled this
  way
• Anticipate Gbps performance, huge window
• Loss gt trickle out over multiple minutes
• Kill the process, and only partial data

6
Actually, adding others

• We found out our back-end infrastructure that we
  somewhat hacked together (really designed for
  Abilene-only owamp and then evolved) wasnt well
  made to deal with multiple federations
• Rethinking

7
Measuring the Demo Lightpath

• Matt Zekauskas, Internet2
• ltmatt_at_internet2.edugt

8
Acknowledgement

• This section started as a talk at the March 2004
  Canarie Lightpath Workshop
• Many of these slides stolen from a presentation
  by Eric Boyd and Nicolas Simar at GNEW 2004 at
  CERN
• http//datatag.web.cern.ch/datatag/gnew2004/progr
  am.html
• http//datatag.web.cern.ch/datatag/gnew2004/slide
  s/boyd-simar.ppt

9
Goals

• Put traffic on the lightpath
• Recall KIDS we were tying together a number
  of technologies, not trying to make the simplest
  or most direct path
• Cooperative measurement of Internet2 and GEANT
  sections steps towards an interoperable
  framework

10
Goals II

• Simultaneously measure three paths
• Normal routed path via DataTag path1LOSA-CHIN
  -StarLight-CERN
• Lightpath path3LOSA-Abilene-CHIN-Canarie-NYCM
  -IEEAF-AMS-SURFnet-DANTE-CERN
• Contrived routed path path2LOSA-Abilene-CHIN-
  Eurolink-AMS-DANTE/London-CERN

11
Goals III

• Show interoperability with other projects
• piPEs data has webservices interface
• MonaLisa (HENP viz for performance data)
• NLANR Performance Advisor (look at performance,
  Web100 variables, give advice based on heuristics)

12
Non-goals

• Given time, direct comparisons of paths
• Normal 9000 MTU, few hops
• Lightpath 4470-n MTU, IEEAF
• Contrived 4470-m MTU, EurolinkLondon
  intermediate had 1500 MTU
• Endpoint machines of differing power
• Consider how to work with real application
  endpoints for lightpaths

13
Capitalize on Existing Infrastructure

• End to End Performance Initiative piPEs
• IP performance centric

14
All Roads Lead to Geneva
15
Results

• BWCTL http//abilene.internet2.edu/ami/bwctl_stat
  us_eu.cgi/BW/now
• OWAMP http//abilene.internet2.edu/ami/owamp_stat
  us_eu.cgi/now
• MONALISA http//vinci.cacr.caltech.edu8080
• NLANR Advisor

16
Insights

• Mostly mechanical/startup issues (see also
  400pieces of email to setup path) just didnt
  have enough time to investigate thoroughly
• We appear to see some loss in one direction
• Using stock stack hurts, web100 data useful but
  not yet available

17
Insights

• Given non-TDM nature of our total lightpath,
  partial path diagnosis would have been very
  useful
• After initial demo, broke out point at NYCM
• 990 Mb/s LOSAlt-gtNYCM via Abilene MPLS and Canarie
  TDM
• Indistinguishable from routed Abilene path
• Points towards transatlantic link or glue into
  GEANT (CERN or SURF) inconclusive

18
Want

• Data from various layer 2 (or 1)
• Ability to insert testpoint into
  middle(addressing? VLANs?)
• As much information from the hosts as possible
  (esp. wrt reordering, loss)
• Hosts if they are lightpath endpoints will have
  primary visibility
• Ability to replace end host with test point

19
ELB Insights (1)

• Even with shared source and a single team of
  developer-installers, inter-administrative domain
  coordination is difficult.
• Struggled with basics of multiple paths.
• IP addresses, VLANs, host configuration, software
  (support source addresses, etc.)
• Struggled with cross-domain administrative
  coordination issues.
• AA (accounts), routes, port filters, MTUs, etc.
• Struggled with performance tuning measurement
  nodes.
• host tuning, asymmetric routing, MTUs

20
ELB Insights (2)

• Connectivity takes a large amount of coordination
  and effort performance takes even more of the
  same.
• Current measurement approaches have limited
  visibility into lightpaths.
• Having hosts participate in the measurement is
  one possible solution.

21
ELB Insights (3)

• Consider interaction with security lack of
  end-to-end transparency is problematic.
• Security filters are set up based on expected
  traffic patterns
• Measurement nodes create new traffic
• Lightpaths bypass expected ingress points

22
Open Research Issuesfor Measurement Federations

• Access and Authentication
• Discovery of Measurement Nodes (Super-Traceroute
  )
• Discovery of Measurement Databases
• Inter-framework Testing
• Compilation of results on partial paths
• Normalization of identical characteristics
  gathered by heterogenous tools

23
(No Transcript)