AUP - we can come up with a reasonable AUP (Rich Carlson, Bill Johnston and Don, and David???).
1) USLHCnet needs a written and visible AUP. We heard in the meeting that its scope is all HEP related Trans Atlantic transfers, not just those to and from CERN. The scope is wider than just data transfers, and also includes mail, videoconferencing, etc. FNAL notes that demarks with the European production networks are not modeled in the drawings it found while prepping for the meeting. Some remarks were made about US requirements e.g.
CALEA. (We did not hear the remark, assume this is well in hand). How US LHCNET is to be use by default routes to and from Trans-Atlantic physics institutes is not clear to Fermilab. We note that currently, ESNET -> GEANT is used for FNAL to (at least IN2P3, KALSRUHE, DESY, and so forth).
2) US LHCNET has plans for bandwidth management technology. The planning assumption is that bandwidth will need to be managed. How the upper levels of bandwidth management policy work is
TBD. Lisa and Ultralight kernel are mentioned as
providing a means to forecast bandwidth use and obtain high single
stream rates. FNAL notes that no system to date has
forced uniform kernel deployments. The existence of one system that forecasts is quite a different matter than finding out how to accommodate all systems that forecast. There are a variety of techniques for presenting a high load to a wide area network.
There are two technological trends. They are approximately characterized as single stream, high rate, multi stream, lower rate.
(the current infrastructure is multi-stream).
3) We have not yet heard of specifics and meat on how end to end circuits will be set up, and to the extent the setup is
automated. It was not clear how the circuits are deployed world-wide.
It seems clear that progress can be made in the US.
Moreover, it seems clear that interoperating automated channel provisioning is in its infancy, and there is work to do.
4) Application awareness everywhere in LHC computing is a daunting task.
Acceptance of network awareness is not omni-present in the LHC data management software community. FNAL notes that Lambda Station interface primitives are in a forthcoming release of dcache.
5) Much of the working group is drawn from people with network-based expertise and skills. To the extent that there are needs to interface with traditionally distinct skills and make decisions, The group should understand that it is not representative of the wide deployment community.
It is not necessary to theoretically derive the existence of a walnut bagel from a point (physicists approach). It is useful to accept the ingredients but figure out the right way to make it (engineers approach).
With that in mind, lets talk about scope since we discussed it at the meeting.
The LHCOPN aims to solve all practical problems around a limited scope (LHC, T0-T1, T1-T1) in a limited time horizon (1-2 years).
The USLHCNet aims to solve all problems around all scope (HEP) in all timeframes, at least I think that’s what Don aluded to.
So the danger with the LHCOPN is that you miss the strategic direction and the danger with USLHCNet is that you only have strategic direction.
So we have to be careful on both fronts. For example on the OPN front it might be appropriate on some timescale to move the lambdas that arrive at CERN onto a new switch capable of bandwidth control and provide therefore an optical switched hub instead of terminating on routers. I have this in mind, possibly, but not yet.
Now to my belief system, which, is of course limited in time. Its always easy to predict an explosion of requirements as it will be almost certainly be true. The trick is when.
Therefore, while bandwidth on demand and application controlled networks may become true, I don’t see the practical problems being solved in the next 5-10 years. Therefore ignoring such things may be construed as not realising the future, but on the other hand, dealing with the here and now is also important, admittedly while trying to create systems open to the future.
Dynamic setup of lambdas (on demand) and advance reservation therefore is something that is an interesting research project. Will work while you have lots of over provisioning and probably has much more interest for network operators than end users. I am not convinced however that the system just does not fail when the network supply and demand ratio approaches unity. Another reason is that there are considerable practical issues on building the L3 on top of the L2 lambdas. Not something the end user can do lightly (or the operator for that matter).
I am much more a believer in varying the width of the laid pipe than changing its endpoint. I think there is much practical value in being able to do that (VCAT/LCAS) as well as laying new pipes in a semi permanent manner as needed. However, neither of these require too much special technology to be able to do today which is their virtue for production networks and their weakness for people doing network research.
Finally on the kernel issues. I think that there does need to be a well publicised, and fairly simple, "best practices" document for setting up systems that need to use networks efficiently. This would be of great benefit, but forget about imposing kernels or submit to a lifetime of pain.
Finally, as I mentioned, the LCG will now push T1's to do real-world practical tests with T2's. We have come to a point where this is on the radar and I expect a lot of attention to now focus on this. I have as yet no real indication how this might be structured (new SC's?) but it will happen, and that will be good especially as the European T2's will start to see their issues.
There are minutes attached to this event.