Thursday, September 18, 2008

Supporting Real-Time Applications in an Integrated Services Packet Network: Architecture and Mechanism

This paper is also a paper on the real-time guarantees of the internet. It explains the details and need of the architecture and mechanisms to allow real-time services in the internet. However, the author's view of real-time applications seem somewhat narrow to mostly multimedia streams or apps that can be categorized as having a "play back point." Although it does distinguish between guarantee service and predicted service, which is probably their way of saying hard and soft real-time tasks.

Both papers recognize that a network needs to support both datagram traffic and real-time traffic. We know that there are pre-existing virtual circuit networks (ATM) out there that guarantee delivery, and there is obviously packet switched networks that don't have guarantee. But based on the previous paper (fundamental design issues for the future internet), they state that having two seperate links doesn't have the most efficacy, but instead, a link that can satisfy different service models is a link that is the most efficient in utilizing it's bandwidth. Thus, this paper is about the different scheduling algorithm required, and how to unify them.

It seems like the effort for real-time internet boils down to a couple general points:
- Need to reserve bandwidth for real-time connections
-Need to have admission control, because real-time guarantees can't be effected by congestion
-Need to have some way to prevent abuse, namely, pricing
- Need to be compatible with current internet, so use leftover bandwidth to complete non real-time packet requests

But none really talk about security issues, they just use pricing as a mechanism to prevent abuse. Intuitively, if there is a real-time guarantee of delivery, then there can't be denial of service attack because the bandwidth is isolated from the rest of the packets. But can we also think of a denial of service when there is an admission control and real-time requests can't be serviced because it will disrupt the current schedule? This seems like an interesting research topic and a good choice for the semester project.

No comments: