We demonstrated by remote access our latest software
for pricing of bandwidth and authorization of user bids. This software includes
integration of SIP signaling, authentication, and resource reservations. The
demo was driven through a web-based interface.
We demonstrated our software at the FTN program
meeting in St. Petersburg, FL. We used for this purpose a testbed of 5 laptop
computers running Linux. Two machines were configured as routers, and supported
our pricing code and our DiffServ code. An overview can be found here.
The software used in these demonstrations is also available.
The demonstrations included the following.
Pricing of network resources
- The ability to set a price for network bandwidth
and store that information in a policy database implemented using MySQL
- The ability of a user to request bandwidth at
a specific bid price. This bid is included in the RSVP PATH message.
- The ability of routers to copy the user bid
into a COPS REQUEST message which is sent to the policy server as part of
the request for resources.
- A policy server implementation which verifies
that sufficient resources are available and that the user is bidding a sufficiently
high price to afford the resource.
- We demonstrated these capabilities with a web
interface that allowed the user to start an application requiring QoS guarantees;
this application was a RealPlayer video presentation. The contents of the
resource policy database were displayed, including the bandwidth availability
and price. The user could request a specific amount of resource at a specific
(bid) price. This request was accepted depending on the bid and asking prices,
as well as resource availabilities. The outcome of resource reservation
affected the video quality immediately and could be viewed.
- A walk-through of the demo, with screen shots,
is available here.
DiffServ attacks and detection
- An interactive audio application was implemented
that allowed a user to speak into a microphone, and play back the audio
across the network in real-time, on another host's speakers. When packet
loss occurred the applications playback buffers were lengthened to allow
time for retransmission. This means playback delay becomes longer and longer.
- Background traffic was generated to load a bottleneck
link with an excessive amount of traffic. The quality of the audio application
remained high because its packets were marked as EF class traffic, and given
preferential treatment by the DiffServ routers.
- Packet dropping by a DiffServ ingress router
was turned on. The effect on the audio application was to immediately increase
the playback buffer substantially to compensate for the unexpected packet
losses; delay thereby went up.
- The effect on performance was also graphically
illustrated by plotting statistics on packet delays and losses
TCP Packet Dropping Attacks
- Previously we had collected data on packet losses
during transmission to 4 different sites (US, Germany, Taiwan, and Singapore)
from N.C. State. We also had implemented a packet dropping attack and collected
data on loss behavior under that attack, to those 4 sites.
- In the demo we analyzed these sets of data on
a laptop computer. The user could evaluate the sensitivity of the tool using
various metrics. The demo also the trade off between probability of attack
detection, and probability of generating false alarms.
last updated 1-February-2002