Faculty of Physics and Astronomy
Minnaert building, Leuvenlaan 4
PO Box 80195
3508 TD Utrecht
WFI-99-01
Date:
27 January 1999
By:
Marcel Sterling & Jos Dieperink
For:
Hogeschool Enschede
Instituut ICT
Postbus 70.000
7500 KB Enschede
Telephone: +31 53 4871300
Fax: +31 53 4305885
Supervisor:
Dr. Ir. C.T.A.M. de Laat
In association with:
Network resource reservation, Performance and modeling.
Table of contents
Table of contents i
1. Organization structure University of Utrecht / Simac. 1
1.1 Organization Structure Simac Techniek NV 1
1.2 Organization structure University of Utrecht. 2
2. Work to be done 3
2.1 information gathering about RSVP: (Chapter 3) 3
2.2 basic RSVP connection set-up tests: (Chapter 5) 3
2.3 Information gathering about OPNET (Chapter 7) 3
2.4 Simulation to be done with OPNET (Chapter 8) 3
3. Relevant RSVP Information gathered 5
3.1 Network forwarding 5
3.1.1 Traffic Classes 5
3.1.2 Elastic Traffic 5
3.1.3 Interaction between Elastic Traffic Streams 7
3.1.4 real-time Traffic 8
3.2 Cisco’s resource reservation implementation 11
3.3 Introduction RSVP 13
3.3.1 Why do we need RSVP 14
3.3.2 Reservation Process 17
3.4 Microsoft QoS Service Provider (QOSSP) 21
3.4.1 QOS-Related Data Structures 23
4 RSVP test environment 27
4.1 RSVP ATM connections 27
4.2 Sub-network University Utrecht 28
4.3 RSVP OS configuration 29
5 RSVP test results 31
5.1 Enabling RSVP 31
5.2 Router static resource allocation 32
5.3 Relationship Flowspec settings and resource allocation 33
5.4 Netperf 34
5.4.1 Test goals 34
5.4.2 Results 35
5.4.3 Conclusion 41
5.5 Dynamic allocation/teardown of resources 42
5.5.1 Dynamic allocation of resources 42
5.5.2 Dynamic teardown of resources 44
5.6 Re-routing of RSVP reservations 45
5.7 Asymmetrical routing 49
5.8 Call Admission Control 50
5.9 MESH 51
6 Cisco bugs and workarounds 53
6.1 Hold-queue 53
6.2 Distributed Weighted Fair Queuing 54
7. The Simulation. 55
7.1 Introduction 55
7.2 What is a Simulation? 55
7.3 Types of Simulation 56
7.4 The OPNET Network Simulation Package Introduction 56
7.5 Modeling and Simulation Cycle 57
7.5.2 Build Models 58
7.6 OPNET as a Discrete Event Simulation Package 59
7.7 Model Specification and Design 59
7.7.1 Network Domain 60
7.7.2 Node Domain 61
7.7.3 Process Domain 61
7.7.4 Parameter Editor 64
7.8 Data Generation 65
7.9 Simulation Execution 66
7.10 Model Validation 67
7.11 OPNET Model Library 68
7.12 Conclusion 70
8. Simulation of RSVP capable network between SEC – UU – UT 71
8.1 Description of the network. 71
8.2 Simulation run 1: Stress test with multiple video streams. 73
8.3 Simulation run 2 76
9. Test network GIGAbit Ethernet. 77
9.1 First simulation run 77
9.2 Second simulation run 80
9.3 Third simulation run 83
9.4 Gigabit Ethernet back to back test 86
10 Recommendations for further research. 93
10.1 RSVP 93
10.2 OPNET 93
11 Final conclusion. 95
12 Acknowledgements 97
13. Literature 99
14. Acronyms used in this report 101
Appendix A. Winsock2 sample call sequences 103
Appendix B. Frequently used CISCO IOS commands 111
Appendix C. Cisco static RSVP commands 113
Appendix D. Running-config 115
Appendix E. What is missing / could improve / bugs. 119
Appendix F. Workaround for patch that uses all CPU time. 121
Appendix G. Solve problems with ATM after patch. 123
Marcel Sterling / Jos Dieperink / Page 123
Network resource reservation, Performance and modeling.
1. Organization structure University of Utrecht / Simac.
1.1 Organization Structure Simac Techniek NV
With more than 1700 people working for Simac, which has a notation at the Amsterdam Exchanges, Simac Techniek NV is a important player on the markets of Information- en communication technology, technologies and Industrial electronics.
Simac works from different places over whole of the Benelux (See Figure 1.1), but also outside this borders more and more offices are opened and/or strong bands are made with other firms outside the borders of the Benelux. Therefore, Simac is expanding on all its fronts.
Cause of this expanding is the turbulent changes in this type of business and the large number of companies that are taken-over by Simac Techniek NV. Nevertheless, Simac is keeping his human character it has since the start in 1971.
Figure 1.1 Organization diagram Simac Techniek NV
Within Simac Techniek NV we work for ICT Netherlands. This holding can be split in several clusters. Each of these clusters is specialized in an area within the Information- and communication technology. We work within the cluster of telematics, a cluster with about 20 people.
1.2 Organization structure University of Utrecht.
We have an agreement with SIMAC, we will work for them and they have detached us to the faculty of Physics and Astronomy at the University of Utrecht. To be more specific the department of Computational Physics.
Within this department, work about 20 people.
1 professor
3 staff personal
1 secretary
± 6 project personal
±10 students
3 graduation students
2 persons from companies
Our research coordinator and supervisor is Cees de Laat. We have two roommates being Marc Jansen doing a final graduate period with Simac and Armin Gerritsen working on a research project for University of Utrecht.
The department is doing a couple of research projects (here are some of them):
v Computational Physics
· Ocean and weather modeling
· Solid state physics
· Supercomputing massive parallel system
· Code distribution and optimization
v Computer based learning systems
· SENS project
· Computer and network based college
· WEB based (Java, HTML, Db, GroupWare)
v EU project REMOT / DYNACORE
· Collaboratories, virtual control rooms
· Support science at the home institutes
· GroupWare, videoconference tools point to point and point to multipoint
· Corba services, distributed objectdb
v Networking
· Focus on applications for physics
· Qos networks for computing, Collaboratories and telelearning
· Distributed system topics:
· Modeling
· Optimization
· Simulation
· Emulation
2. Work to be done
2.1 information gathering about RSVP: (Chapter 3)
· Gather and present information on RSVP standards (best effort Û controlled load, guaranteed)
· Gather information on operating system dependent RSVP implementations for:
ü Windows 95, 98, NT
ü UNIX (we only look into Digital UNIX and Linux)
· Information on router operation with RSVP {CAR, WRED, WFQ}
· Determine the software/hardware architecture to be used in the subsequent tests. Produce reference drawings such that all partners know what we are talking about and finally look into VLAN structure with ACCU.
· Adapt, create, obtain RSVP test applications and tools
2.2 basic RSVP connection set-up tests: (Chapter 5)
· Initiate connections, both with in-band as out-of-band signaling.
· Repeat the traffic management test as done last year with UNI Geneva. Make a small link, run generic traffic on it while bandwidth is reserved by RSVP for one link. Switch traffic on that link on and off and see what happens on all the links.
· RSVP under extreme conditions for controlled load, guaranteed and best effort
· Heavy loaded router interface (many packets to route, high bandwidth in use)
· Many RSVP set-ups (>100 RSVP connections simultaneously)
· Small outgoing pipes and loads balancing in there.
· Re-routing of RSVP reservations when link fail occurs.
· Routing of RSVP reservations within an asynchronous network.
· Call Admission Control to grand/deny users resources.
2.3 Information gathering about OPNET (Chapter 7)
· Gather information about RSVP capable models for OPNET
· See if any of the vendors have a RSVP capable OPNET model
2.4 Simulation to be done with OPNET (Chapter 8)
· Test the opnet simulator and check if it is a useful tool
· Make a simulation model of the test network that is used for RSVP testing and to the same basic RSVP connection tests as mentioned in 2.2
· Do simulations on various computer networks
3. Relevant RSVP Information gathered
The information gathered will give more insight about how RSVP works and how it is implemented by different vendors.
The first two articles are published by Cisco, looking at RSVP from the network side. The last two articles have different publishers, handling RSVP from the computer side.
3.1 Network forwarding
(Source: Interface queue management
Cisco
http://www.cisco.com/warp/public/614/16.html )
In the past, forwarding systems (switches, bridges, or routers) have not sought to optimize the behavior of traffic in an internetwork. Vendors have generally considered this capability to be unnecessary, because hosts implement algorithms that control the rate of traffic generation. Traffic problems have essentially been seen as host algorithm problems. However, data network managers have known this theory to be untrue (or at least unworkable), and have pressed for ways to prioritize traffic or to allocate bandwidth. They have often had a very personal motivation -- their users detect network slowdowns and call to inquire.
Research within the past decade has shown that aggregate traffic behavior in the Internet requires care on the part of the forwarding system as well. To effectively serve the needs of users, the forwarding system must optimize several traffic attributes:
· Bandwidth allocation
· Delay variability
· Timely delivery
· Delivery reliability
3.1.1 Traffic Classes
To understand the solutions and their effects, it is necessary to understand the internetwork traffic patterns. Traffic patterns fall into two major groups, and each major group has two subgroups. First traffic is either "elastic" (adapts easily to change), or real-time. If it is elastic, it is both interactive and therefore sensitive to delay, or it is a bulk transfer of data and is therefore sensitive to bandwidth. If it is real-time traffic, it requires that the network not lose traffic very often, but guarantee a certain throughput rate, or it accepts loss of traffic in exchange for priority service in order to maintain timeliness of delivery. These real time service classes are called guaranteed and predictive service, respectively.
3.1.2 Elastic Traffic
Elastic traffic is nothing more than traditional best-effort message delivery, which has been the staple of datagram internetworking for about two decades. It has not dramatically changed, but is better understood now than it was in the past. This traffic is "elastic" because it adapts to changing network conditions without losing its usefulness. If a file transfer is traversing several T1 lines and LANs, and a routing change forces it to use a congested 56-kilobit line, the transport slows down to accommodate the new path.
There are two basic classes of elastic traffic: traffic generated by interactive or transaction-oriented applications and bulk transfers of data.
3.1.2.1 Interactive and Transaction-Oriented Traffic
The classic interactive application is the Telnet-based terminal server or terminal emulator running on a personal computer. Interactive traffic is essentially random, perhaps because humans typing on keyboards do so erratically and randomly. Such applications generally accumulate characters for a short period and then transmit them to the peer application; it acknowledges them, often by sending the same traffic back.
This method is called "echoplex" transmission. Since new transmissions wait until an outstanding transmission has been acknowledged, this type of application is very sensitive to delay.
Transaction-oriented applications are similar but have important differences. The classic transaction application is perhaps X Windows or SNA-based data entry. In these applications, the accumulation of information lasts longer, and transmissions contain more information. The user is effectively unable to continue working until receiving the response, because the response is a new screen or the next question.
In both cases, the traffic generation rate is essentially random, but once traffic generation starts it often continues in short bursts. As an intuitive example, a writer starts to write a word. His typing is somewhat erratic as he stops and thinks of the next sentence or pauses for reflection, but when he types he sends a burst of small messages containing a few characters each. B.B. Mandelbrot developed a similar ("fractal") model in part to describe systems that behave in this way; the probability of an event (a message being sent) is not a purely random function as in the more conservative Poisson model, but a random function of the amount of time since the previous message. Current research indicates that the Mandelbrot model may effectively describe interactive and transaction traffic in an internetwork.
The use of the Mandelbrot model has useful and interesting implications. It means that traffic patterns viewed over a long period have many of the characteristics of more fine-grained traffic patterns in a short time.
3.1.2.2 Bulk Transfers
The classic bulk transfer application is a file transfer protocol (FTP). Such protocols do their work in different ways, but essentially seek to use the network to move large amounts of data in a short amount of time.
The FTP application operates by opening what amounts to a Telnet connection to a remote peer and negotiating services over that. When one system sends a file to the other, they open a TCP connection for the data. The receiver grants a credit to the sender, indicating that the sender may send a certain amount of data, often 4096 bytes. The sender sends a burst of messages containing that amount of information. The receiver acknowledges segments as it receives them and grants new transmission credit in the same message. The sender continues to issue small bursts of messages until the transfer is complete. Then the systems close the TCP connection. This behavior is clearly sensitive to the available bandwidth, but is relatively insensitive to delay.
Apple Computer's AppleTalk alternately sends bursts of messages and waits for their acknowledgement. Since the network links meter traffic delivery, this is very sensitive to available bandwidth. It is also sensitive to round-trip delay, because the acknowledgement is a response to the last message in the burst, and its receipt triggers transmission of the next burst.
The feature common to these traffic classes from the network's perspective is that they both produce packet trains -- bursts of messages that tend to move through the network together. Packet trains tend to alternate rather than commingle. The hosts originating them send the entire amount permitted by their receivers at the rate that their local interfaces permit.
Another feature of these classes is that they try to fully utilise the connecting bandwidth. If little bandwidth is present, the acknowledgement rate is also slow, as is the rate of new credit grants. If the network is fast, it expedites delivery, acknowledgement, and credit. The credit grant rate is as fast as traffic delivered to the receiver, so the sender is automatically tuned to the rate of the network.