Hello, warm. I'm Luca Basi. I'm a computer science student at University of
Bolonia. I'm doing a scholarship funded by Garra, ATI and F and Knaf in
Bolonia. Today we'll present a site acts that is initiative for network
traffic tagging for scientific computer. Let me introduce a little bit
the environment. So we're talking about scientific communities that
move very large amounts of data between small and large data
center, in particular using the connectivity provided by national
research and location networks. One of these is the Italian one that is
called Garra. That is, for example, provide a whopping 1.6-terabit per second
connections between the Knaf data center in Bolonia. That is the National
Military Center of Italy, National Institute for Nuclear Physics and
Bechern. That's probably, you know, in Geneva. And all of these with a
latency for whole year, nine and half milliseconds thanks to multidermaine
shared spectrum. So we need to bear with this amount of data transfer better
understand and understand of the network traffic and how to optimize it to ensure
to use the network as effective as possible. The worldwide LAC computing grid is
distributed computing infrastructure that supports the storage and distribution
and the analysis of the data produced by the large
other on colliders experiments in Geneva. And we have like one more 170 sites
around the world. There is the Tier 1, the Tier 0, that is one in Geneva. 14 Tier
1s and one of these is the one in Bolonia managed by Knaf. And 100 and
half Tier 2 around the globe. So the is quite complex to manage that
transfer between all these sites and provide data with a lot of
latency to all physics around the world. So the site access initiative was
burned to provide the intensification of science domain and their
high level activities of an actor level and this can be done with the
rising packet and flow market. In particular, this is important for
network providers to identify with the traffic owner and the purpose of
these traffic for the experiments to understand out there that are flows
performed along the complex network path and to sites so to data center to
game visibility into our very different data flows performs around the network.
In particular, stacks provides two ways to mark a network traffic flow marking
with the UDP for flies and packet market, packet marking using the IPvsa flow
label, either field invader. Each flow can be identified with two
information, the experiment and the activity of the experiment. For example,
if we take the address experiment, that is one of a major experiment at
Sharon that has experimented the two, that is doing data consolidation activity
that has ID4, the error will be shot at 100, 30. All the these ID are
statically mapped at the moment in a flow registry. That is just a JSON file with
this information. So let's talk about the two way to mark traffic and let's
start with flow label with UDP for flies. Fresh flies are just simple UDP
packets in a six log format with a defined JSON body. Packets are intended to be sent to
the same host of destination of a traffic to a specific port and and this packet
that is intended to be work-radable because we want that all the arrays and network
provider that receive this traffic, cool intercept is UDP fly flies and every formation
about the network traffic. Also, the packets could also be sent to a specific
regional global collectors if the sites prefer. They use of CSLog format was because
it's easy to reuse a radius tablish tool, for example log session and these type of
marking was for IPv4 and IPv6. Content is not limited but is limited as long as fit a
single frame. The other way to mark traffic is with IPv5 label invader. So I
BFF traffic control program is to insert these information, the site-axing
information in the IPv6 flow label. Some is a 20 bits long field, some are used for entropy.
So I random, some from the communities of experiments that produce the activity and
some other bits are used for the activity. Actually, we are proposing these two AETF
with IRFC and is available to link invaders if you're curious to a specific
to a specification of this part. So now let's see implementation of
standard web data of site-axing software used in WICG. So let me introduce storm,
storm stands for storage resource manager. Is a grid storage solution for this base storage
system with a POSIX file system, typically is a distributed file system such as
GPSS. In particular in WICG, storm is adopted by the tier 1 of set-out knaff and by some
other tier 2. In particular storm is a suite of software and today we will talk about specifically
about some web data. That is one that provides connectivity, provides functionality
through web data protocol. The web data protocol is an extension of the HTTP protocol that
allow to manage files on a remote server. For example, we added some new HTTP verbs, for example,
MK call to create a directory or copy to copy the file remotely. And in particular, it's
on WebDub, it implements an extension of the copy verb of WebDub. So an extension of an extension
that is called third-party copies. And these are a really useful functionality because
permits to transfer data between data center without actually doing some local copies. So you can
say to a remote server copy the file that you have locally to these other remote endpoint or
get to these files from these remote endpoint and copy to your remote storage. So that is the
most used functionality through transfer data between the various data center in WICG.
The latest release of Storm WebDub has obtained support for Site-Eyes Ailer.
In particular, it relies on Flodim. Flodim is a demon that has different plugins to retrieve
the flow information and a set of commands to mark the traffic. In particular, Storm WebDub
used the NPAPI plugin to retrieve the one to receive identifiers through an impipe. And
sends the UDPFrive flies using Flodim. So Storm WebDub writes a line to a specific file in this
form, where a state is start-to-end of the flow. The protocol, so TCP or RDP,
the source IP import, the mediation IP import, and the information extracted from the Site-Eyes Ailer.
So we experimented in the activity ID. So let's see how the third-party copy in push mode.
Also, copy this file that you have, log it to this remote server, worse using Site-Eyes Ailer.
The client to HTTP copy request specifying a remote destination. In this case, we are sending
this request to server-racing, copy this file to destination B. And in the request, it is included
the Site-Eyes Ailer. In this case, 65 or random. Storm WebDub received a request. Start
doing the HTTP put request to server B as extracted by the HTTP copy request. And at the same
time, send the information about activity ID experiment ID to the flow, the Demon, that send
the UDP file files. The transfer continues, and when the transfer ends, Storm WebDub communicated
the end of the network flow to flow D, and flow D send the UDP file files containing the information
that the transfer of the file is ended. So to sum up, Site-Eyes permits to mark packets
and network flow with information about experiments and activity responsible for a network
traffic. The latest release of Storm WebDub has obtained support to these two parts of
this information. And at the moment, is in development, a parting of the moment is written
in Python, and we are also exploring to use other fields in the IPv6 Ailer instead of a
flow label. We are trying with the destination option, a copy option as alternative. So thank
you for your attention. You refine the website of Site-Eyes Initiative. There is a mail list.
We are open to contribution for other type of scientific experiments. At the moment, we are
mainly eye-energy physics because this initiative was born and served, but we are open to
other type of scientific experiment, the source code of the webDub, and all the Site-Eyes
contributors. So thank you. And if there is question.