Download III. Dummy section heading for formatting

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

TCP congestion control wikipedia , lookup

Internet protocol suite wikipedia , lookup

Asynchronous Transfer Mode wikipedia , lookup

Piggybacking (Internet access) wikipedia , lookup

Computer network wikipedia , lookup

Airborne Networking wikipedia , lookup

Zero-configuration networking wikipedia , lookup

Peering wikipedia , lookup

Network tap wikipedia , lookup

Distributed firewall wikipedia , lookup

Recursive InterNetwork Architecture (RINA) wikipedia , lookup

Wake-on-LAN wikipedia , lookup

List of wireless community networks by region wikipedia , lookup

Cracking of wireless networks wikipedia , lookup

Net bias wikipedia , lookup

Deep packet inspection wikipedia , lookup

Quality of service wikipedia , lookup

Transcript
> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) <
1
Diversifying the Network Edge
Fred G. Kuhns, Michael Wilson, and Jonathan Turner

Abstract: The Internet has become an indispensable part of
global commerce, government operations, distribution of media
and communications. With success has come a growing
ossification resulting in limited opportunity to address
fundamental architectural issues or deploy disruptive
technologies. A recent call to arms[1] advances a research agenda
to create a virtual testbed to overcome three barriers to effective
architectural research: live testing, deployment and broad-based
solutions. In this paper we take up the challenge and propose the
Network Diversification Architecture as a virtualization scheme
permitting multiple networks to operate over a common
infrastructure without interference. Network diversification
enables live testing and deployment of innovative architectures
and services without disrupting existing network operations.
We present the architectural model and focus on the LAN
environment looking at support required within end-systems,
LAN devices and last hop routers. Our contributions are an endto-end virtualization model, extensible end-system networking
subsystem architecture and specification of LAN virtualization
services.
Index Terms—extensible networks, virtual networks, protocols,
operating system extensions
I. INTRODUCTION
The Internet has become an indispensable part of global
commerce, government operations, distribution of media and
communications. On a personal level, the Internet has changed
the way we interact with the world and organize our lives. The
original design criteria are in large part responsible for this
success: independent networks, stateless gateways and
universal access [History]. Over the years the Internet
architecture has proven to be remarkably adaptable and
extensible enabling the relatively rapid expansion from a small
research network to the world wide infrastructure we have
today. However, as pointed out in [Overcoming] the very
success of the Internet is now leading to its ossification. This is
especially visible when comparing the data and voice
communication industries. Historically the telecommunication
Manuscript received XXX 2005. This work was supported in part by the
XXX
F. G. Kuhns. is with the Computer Science and Engineering Department,
Washington University , St. Louis MO. 63130 USA, (314-935-6598; email:
[email protected])
XXX Author is with the Computer Science and Engineering Department,
Washington University , St. Louis MO. 63130 USA, (email:
[email protected])
XXX Author is with the Computer Science and Engineering Department,
Washington University , St. Louis MO. 63130 USA, (email:
[email protected])
industry has been steeped in procedures where the introduction
of new equipment and features often takes years of
standardization, testing and verification. Contrast this with the
relatively swift rate at which data communication vendors have
deployed systems feature rich with the latest technological
advancements, often independent of a clear demand. Of course
this has all changed due to the rapidly increasing importance
of data communications and its commensurate increase in the
market share. The industry is demanding greater reliability and
integration.
Ironically, this ossification is at a time when change and
adaptation is becoming ever more important. Security,
performance, scalability and management complexity are all
problems directly impacting the very corporate, government
and individual users who have become so dependent on the
existence of a dependable and secure Internet infrastructure.
Consequently efforts to address issues with the existing IP
infrastructure are hampered by the concomitant concern over
network reliability and cost of ownership. Introducing
architectural changes or new services requires a general
consensus of all stake holders, each with their own set of
interests and concerns. Plus there is the distinct possibility that
introducing disruptive technologies could lead to network
destabilization and increased management complexity.
Consequently changes to the current architecture are limited to
incremental changes or band aids [Diversify].
As pointed out in [Overcoming], architectural innovation
has continued despite the many barriers to live testing and final
deployment. To enable live experimentation with new services,
researchers have looked to varying forms of network
virtualization to permit widespread deployment and testing in
realistic settings. This virtualization has ranged from simple
overlay networks as in M-BONE and 6-BONE, to more
comprehensive
approaches
which
address
critical
management, control and isolation issues [X-BONE,
PlanetLab]. Related efforts have considered mechanisms [i3,
SelNet] for transparently allowing clients to access these new
service specific overlay networks (is this true for SelNet?).
These overlay networks have generally assumed IP is used
both for tunneling and as the tunneled protocol thereby
restricting the architectural scope of deployed test networks.
Likewise, experimentation to date has been focused on
addressing specific, narrowly defined problems.
In this paper we take up the challenge proposed in
[Overcoming] and devine the Network Diversification
Architecture (NDA) -- or Diversified Networking Architecture
- DNA -- as a virtualization scheme permitting multiple
> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) <
Substrate Bandwidth Management
100
90
Throughput (Mb/s)
80
70
60
15 Mb/s Flow
30 Mb/s Flow
Best Effort
50
40
30
20
10
48
44
40
36
32
28
24
20
16
8
12
4
0
0
networks to operate over a common infrastructure without
interference. Network diversification enables live testing and
deployment of innovative architectures and services without
disrupting existing network operations. We see PlanetLab as a
very promising framework for creating virtual testbeds and
may serve as a role model for defining a new internetworking
architecture which permits multiple virtualized networks to run
concurrently over a common infrastructure but without
interference. The current IP based Internet may then simply be
one of possibly many different networks all sharing a common
set of networking resources. However specialized networks (or
specialized versions of an IP network) could coexist providing
innovative services and enhanced capabilities.
In this paper we present the …. Section X a …
2
Time (s)
Figure 1: Throughput with locally competing flows
The results in Figure 1 show that the traffic isolation works
admirably in the end system. Each vNet flow receives the full
bandwidth up to the rate ceiling. While overhead both in the
linux token bucket implementation and Ethernet itself prevent
perfect utilization at the exact specified rate, this could be
compensated by careful rate selection.
Packet loss information (not shown) shows negligible
packet losses for this experiment. Because all rate control is
performed at the end system, the intervening switch never has
a need to drop packets in response to congestion.
Substrate Bandwidth Management
100
90
80
70
60
50
40
30
20
10
0
64
72
48
56
32
40
15 Mb/s Flow
30 Mb/s Flow
Best Effort (Local)
Best Effort (External)
8
16
24
0
Implementing the architecture described in III and IV
requires that we be able to isolate network traffic in both the
end system itself and the LAN. Mechanisms exist in most
modern LAN switches for 802.1P/Q per-packet prioritization
and per-priority queuing of traffic. We gain isolation by
placing vNet traffic in a higher priority class than legacy and
best-effort raffic.
Mechanisms also exist in the end system for traffic control.
In our experiments, we use the linux queue discipline structure
to isolate vNat traffic by (1) placing vNet traffic in a higher
priority queue, and (2) rate limiting all vNet traffic to selected
maximum sending rates.
Our experimental testbed consists of three linux machines
running linux 2.6.11 on two machines and 2.4.17 on the third.
One 2.6.11 machine is chosen as a virtualized sender; the other
is our receiver, and the 2.4.17 machine represents a legacy
machine with best effort traffic.
Our linux nodes are directly connected to the same switch,
an HP ProCurve 2424M, which has been configured to respect
802.1P/Q prioritization. Our substrate capacity is 100 Mb/s
full duplex.
I’m not sure how much we need to explain about our
mechanism implementations in the testbed. This is the
complete version – we can always crop it down as needed.
Both 2.6.11 machines have VLANs implemented for VID’s
1024 and 1025. Since only one machine will be sending
virtual network traffic, the queuing disciplines are only
implemented on this machine.
We implemented our queuing scheme with the linux PRIO
class at the top level. All vNet traffic is classified into the high
priority band, and all legacy and best effort traffic is classified
to the low priority band. In the high priority band, we also
subclass with two flows limited to 15 Mb/s and 30 Mb/s,
respectively.
Our network traffic flows are implemented with iperf,
configured to attempt to send UDP traffic at 100 Mb/s, the line
rate. Assuming no prioritization at all, all flows would roughly
balance out to the same throughput.
For our first experiment, we ran a set of three overlapping
flows.
Flow Rate
1
15 Mb/s
2
30 Mb/s
3
Best Effort
Throughput (Mb/s)
II. EXPERIMENTAL RESULTS
Time (s)
Figure 2: Throughput from externally competing flows
In Figure 2 we demonstrate that the 802.1P/Q per-priority
packet queues successfully isolate traffic flows. Both rate
controlled flows have been assigned to priority 7, the highest
in use. The best effort flows default to priority 0.
This experiment duplicates the configuration of the first
experiment, with the addition of a second best effort flow from
> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) <
a second, legacy machine. Again, all iperfs attempt to send at
line rate. On our vNet host, the vNet flows are rate limited as
above.
These results show the same isolation as before. The vNet
flows continue to obtain the assigned throughput despite the
aggregate 200 Mb/s attempted sending rate to the destination
host.
We should probably discuss why the two best effort flows
don’t fully balance out. I can understand why they don’t for
cases where vNet traffic is present – after all, it’s just the
balance of the bandwidth. Once the vNet traffic is done, I’d
expect them to balance out – but they don’t. Any ideas?
Packet loss (Percentage of Total)
90
Dummy text for formatting. Dummy text for formatting.
Dummy text for formatting. Dummy text for formatting.
Dummy text for formatting. Dummy text for formatting.
IV. RELATED WORK
REFERENCES
[1]
[2]
[3]
[4]
[5]
Packet Loss (Percentage)
80
[6]
70
60
50
Best Effort (Local)
Best Effort (External)
40
[7]
30
20
10
[8]
0
1 7 13 19 25 31 37 43 49 55 61 67 73 79
[9]
Time (s)
Figure 3: Packet Loss as a percentage of total packets sent.
Note that the rate limited flows have no losses at all.
I’ve added the packet loss chart here, but I expect we’ll
almost certainly cut it.
In the prior experiment, all traffic shaping took place at the
end system. In this case, the switch also shapes traffic by
dropping packets. Because this creates a switch congestion
situation, the packet losses become significant. In our
experiments, we do not implement any congestion control, so
packet losses in the best effort flows are extreme. However,
this congestion situation is no different from any other
encountered on the Internet. Protocols such as TCP will
reduce the sending rate accordingly and mitigate the losses.
As expected, the rate limited flows experience no packet
losses.
[10]
[11]
[12]
[13]
[14]
[15]
[16]
III. DUMMY SECTION HEADING FOR FORMATTING
Dummy text for formatting.
Dummy text for formatting.
Dummy text for formatting.
Dummy text for formatting.
Dummy text for formatting.
Dummy text for formatting.
Dummy text for formatting.
Dummy text for formatting.
Dummy text for formatting.
Dummy text for formatting.
Dummy text for formatting.
Dummy text for formatting.
Dummy text for formatting.
Dummy text for formatting.
Dummy text for formatting.
Dummy text for formatting.
3
[17]
[18]
L. Peterson, S. Shenker, and J. Turner. Overcoming the Internet impasse
through Virtualization. in ACM HotNets-III. 2004.
Advanced Routing and Traffic Control, http://lartc.org/
HTB, http://luxik.cdi.cz/~devik/qos/htb
Marko Zec, Implementing a Clonable Network Stack In the FreeBSD
Kernel, Proceedings of USENIX Technical Conference, pages 137-150,
June 9-14, 2003
P. H. Kamp, R. N. M. Watson, Jails: Confining the omnipotent root,
Proceedings of the 2nd International SANE Conference, May 2000
A Bavier, M Bowman, B Chun, D Culler, S Karlin, S Muir, L Peterson,
T Roscoe, T Spalink, M Wawrzoniak, Operating System Support for
Planetary-Scale Network Services, Proceedings of the 1st USENIX
Symposium on Networked Systems Design and Implementation, pages
253-266, March 2004
G Back, W Hsieh, J. Lepreau, Processes in KaffeOS: Isolation, Resource
Management, and Sharing in Java, Proceedings of the 4th Symposium
on Operating Systems Design and Implementation, pages 333-346,
October 2000
R Wahbe, S Lucco, T Anderson, S Graham, Efficient Software-Based
Fault Isolation, Proceedings of the 14th Symposium on Operating
Systems Principles, pages 203-216, December 5-8, 1993
Parveen Patel, Andrew Whitaker, David Wetherall, Jay Lepreau, Tim
Stack, Upgrading Transport Protocols using Untrusted Mobile Code,
Proceedings of the 19th ACM Symposium on Operating Systems
Principles, Pages 1-14, October 2003.
Herbert Bos, Bart Samwel, Safe Kernel Programming in the OKE,
Proceedings of the fifth IEEE Conference on Open Architectures and
Network Programming, June 2002
Marc Fiuczynski, Brian Bershad, An Extensible Protocol Architecture
for Application-Specific Networking, Proceedings of the Winter
USENIX Technical Conference, pages 55-64, January, 1996
Norman Hutchinson, Larry Peterson, The x-kernel: An Architecture for
Implementing Network Protocols, IEEE Transactions on Software
Engineering, 17(1):64-76, January 1991
Chandramohan A. Thekkath , Thu D. Nguyen , Evelyn Moy , Edward
D. Lazowska, Implementing network protocols at user level, IEEE/ACM
Transactions on Networking (TON), v.1 n.5, p.554-565, Oct. 1993
Chris Maeda, Brian Bershad, Protocol Service Decomposition for HighPerformance Networking, Proceedings of the 14th ACM Symposium on
Operating Systems Principles. December 1993, pp. 244-255.
Aled Edwards , Steve Muir, Experiences implementing a high
performance TCP in user-space, Proceedings of the conference on
Applications, technologies, architectures, and protocols for computer
communication, p.196-205, 1995
Kieran Mansley, Engineering a User-Level TCP for the CLAN Network,
Proceedings of the ACM SIGCOMM workshop on Network-I/O
convergence: experience, lessons, implications, Pages: 228 – 236, 2003
P Barham, B Dragovic, K Fraser, S Hand, T Harris, A Ho, R
Neugebauer, I Pratt, A Warfield, Xen and the Art of Virtualization,
Proceedings of the 19th Symposium on Operating System Principles,
pages 164-177, October 19-22, 2003
A Whitaker, M Shaw, S Gribble, Scale and Performance in the Denali
Isolation Kernel, Proceedings of the 5th Symposium on Operating
Systems Design and Implementation, pages 195-210, December 9-11,
2002