1 / 7

ANSE Issues and Opportunities

ANSE Issues and Opportunities. Shawn McKee University of Michigan ANSE 1 st Collaboration Meeting Caltech , May 6-7, 2013. Required Functionality. For ANSE we are targeting augmenting ATLAS and CMS software stacks with “network awareness”

tola
Télécharger la présentation

ANSE Issues and Opportunities

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. ANSE Issues and Opportunities Shawn McKee University of Michigan ANSE 1st Collaboration Meeting Caltech, May 6-7, 2013

  2. Required Functionality • For ANSE we are targeting augmenting ATLAS and CMS software stacks with “network awareness” • In practice I think this means that we will provide ATLAS and CMS with two primary capabilities: • The ability to easily access network “information” (quality, coverage and details TBD) • The ability to interact with/control network parameters (path, bandwidth, resiliency/fail-over, preferences regarding latency vs jitter vs bandwidth vs packet-loss, etc.) NOTE: this may(should?) include the end-hosts • Our challenge is on how we plan to deliver this capability. ANSE targets leveraging existing capabilities wherever feasible • We have years of experience (Supercomputing, UltraLight, PLaNets, DYNES, etc) working in the HEP networking space and our goal should be to make it as easy as possible for the experiments to benefit from known useful capabilities in networking.

  3. ANSE “Software” Perspective • I was trying to think of the ANSE software’s perspective. Assuming we have a library of capabilities organized in a coordinated package I would ask some questions: • Where do I learn about the network so I can let ATLAS and CMS have accurate understanding of the network? Possible answers: • SNMP to devices • perfSONAR metrics • Data logs (gridftp logs, DDM logs, FTS logs, etc) • Topology information (from where though? NSI?) • Others? • How can I exert control and/or interact with the network to better achieve my goals? • DYNES/Autobahn point-to-point circuits • OpenFlow or SDN in general • End-system configuration (net stack, ethtool, /proc, ‘tc’, etc) • Traffic marking, source-based routing, etc.

  4. DYNES • ANSE specifically targeted DYNES. The DYNES instrument should provide the ability for DYNES sites to setup guaranteed bandwidth “circuits” between DYNES switches at the source and destination. • Two MAJOR issues we are facing: • There are significant problems in getting the underlying ION/OSCARS software to work reliably for DYNES • When circuits are setup we are NOT currently guaranteeing the bandwidth along the end-to-end path • We have a few more months in DYNES to resolve these issues. I believe they are critical for ANSE as well because we need to have DYNES capabilities in our toolkit. If DYNES is non-functional or marginal at the end of the DYNES grant, sites will repurpose DYNES equipment and our goal of broadening E2E circuit capability will be lost. • ACTION ITEM: Determine how to make DYNES a success…and do it

  5. perfSONAR • The R&E networking community has converged on perfSONAR as the means of organizing and gathering network metrics as well as a vehicle to include “on-demand” test points at participating sites. • While perfSONAR has lots of shortcomings it is broadly supported and we don’t have any alternatives realistically. • Therefore from the ANSE perspective we need to plan on using perfSONAR as part of our network information gathering. • As we identify problems we should push for fixes getting back into perfSONAR. (perfSONAR can be improved and we should help) • We should start immediately on accessing and understanding the information perfSONAR is collecting. • OSG is prototyping an OSG Network Service (modular dashboard deployment) which may end up hosting all WLCG data • WLCG is planning that ALL Tier-2 sites deploy, register and run perfSONAR-PS instances (once v3.3 is out)

  6. Looking Ahead… • In late Fall 2014 what might the experiments “see” via ANSE? • Can we provide some level of end-system diagnosis and tuning to better enable use of the network? Remember problems are typically end-to-end and even with a perfect, lossless network, bad behavior by the end-host or end-host application can cause poor performance • Will the experiments have a sufficiently real-time, accurate view of the network they have access to? At what level of detail and with what latency? • Are the set of metrics provided, filtered and summarized from ANSE appropriate for the experiments to make good choices about their use of the network? • Can the experiments “control” aspects of the network between their sites? How many paths is this possible on? Can the experiments easily discover where “control” is possible and use it? • These questions are (intentionally) too ambitious…lets discuss…

  7. ThankS!Questions, DISCUSSION, COMMENTS? smckee@umich.edu

More Related