This paper compares different techniques for improving TCP performance and evaluates them in the context of wireless links. The main 3 categories that they evaluated were end-to-end protocols, link layer protocols, and also split connection protocols. The results of the paper showed that link layer protocols were the most beneficial if they are TCP aware.
Thinking back on the various papers we read about TCP, when it was designed, the major issues that we read about were mostly about contention and congestion. Several switch design papers proposed mechanism to deal with congestion, and combined with TCP's resend mechanism it would prevent contention. However, now that we're using TCP over a very lossy link, if the guarantee mechanism was only on the end points, then if the link is lossy, we would possibly need to resend over and over again because the probability of packet loss is high in the middle of transit. Thus, intuitively, it's more beneficial to implement recovery services also at the link layer because of the lossy attributes at each link (back to the end to end argument). All in all, a comparison of different mechanisms for TCP over wireless links confirmed the intuition.
Tuesday, September 30, 2008
MACAW: a media access protocol for wireless LAN
This paper proposes a different MAC protocol for wireless medium which uses a request to send-clear to send-DATA packet exchange and binary exponential back off. There were several insights in the paper that led to this protocol:
1. The relevant congestion is at the receiver, not the sender. The paper provides a simple example to show this, by using 3 nodes (ABC) which A cannot hear from sender C and C can't hear from A, the author shows that both A and C can think the channel is clear and send, but contention happens at B when he is reciving.
2. Congestion is not a homogeneous phenomenon. The author states that it is not valid to only have a single backoff parameter, but we need separate back off parameters for each strem.
3. Congestion levels should be a collective enterprise. I felt like this was sort of related again back to the end to end arguments in which functionality need to be carefully evaluated as to where it is implemented. In this case, the author argues that individual congestion detection will lead to asymmetric views of the network, thus there should be a collective effort to create a better view.
4. the protocol should propagate synchronization information about contention periods, so all devices can contend equally.
While reading this paper, one thought related to the project came into mind, which is the guaranteed service for wireless LANs. I've read several papers on real-time ethernet or real-time LAN protocols which use token based mechanisms. But how well would those work for wireless environments? And how much synchronization mechanisms need to be introduced in order to easily guarantee service through a physically unreliable channel?
1. The relevant congestion is at the receiver, not the sender. The paper provides a simple example to show this, by using 3 nodes (ABC) which A cannot hear from sender C and C can't hear from A, the author shows that both A and C can think the channel is clear and send, but contention happens at B when he is reciving.
2. Congestion is not a homogeneous phenomenon. The author states that it is not valid to only have a single backoff parameter, but we need separate back off parameters for each strem.
3. Congestion levels should be a collective enterprise. I felt like this was sort of related again back to the end to end arguments in which functionality need to be carefully evaluated as to where it is implemented. In this case, the author argues that individual congestion detection will lead to asymmetric views of the network, thus there should be a collective effort to create a better view.
4. the protocol should propagate synchronization information about contention periods, so all devices can contend equally.
While reading this paper, one thought related to the project came into mind, which is the guaranteed service for wireless LANs. I've read several papers on real-time ethernet or real-time LAN protocols which use token based mechanisms. But how well would those work for wireless environments? And how much synchronization mechanisms need to be introduced in order to easily guarantee service through a physically unreliable channel?
Tuesday, September 23, 2008
Scaling Internet Routers using Optics
Reading the other paper puts this paper into perspective. This paper further motivates the same subject of switch and router designs and suggests that a cross bar is not enough for the router, but we should use optical networks to scale and reduce power. This paper goes into a good amount of detail about the design and also multi racks for routers. It also lists the different challenges and possible solutions that will be faced when actually implementing this architecture of using optics.
As mentioned in the previous blog, i don't have a lot of background on this subject of matter, thus it was a hard paper for me to read. But this paper does seem to go in a fair amount of detail in the design. One thing that i started thinking about is ways to characterize the router's delay. Since our research project involves an estimation of network delay, it seems that as routers are scaling faster and faster, and as the structure gets more and more complicated, an estimation of the delay will become harder and harder.
It's also interesting that as other electronics are getting smaller and smaller, it seems that the router is growing bigger and bigger. This paper suggests that we would need multiple racks because of the power consumption and heat dissipation , instead of a single rack.
As mentioned in the previous blog, i don't have a lot of background on this subject of matter, thus it was a hard paper for me to read. But this paper does seem to go in a fair amount of detail in the design. One thing that i started thinking about is ways to characterize the router's delay. Since our research project involves an estimation of network delay, it seems that as routers are scaling faster and faster, and as the structure gets more and more complicated, an estimation of the delay will become harder and harder.
It's also interesting that as other electronics are getting smaller and smaller, it seems that the router is growing bigger and bigger. This paper suggests that we would need multiple racks because of the power consumption and heat dissipation , instead of a single rack.
A fast switched backplane for a gigabit switched router
This paper motivated using switched backplanes for router designs. Although i don't have too much background in this area of specific router design, but it seems like the backplane they were talking about was basically the interconnect within the router that connects the input to output. It seems that previous to this paper, this interconnect was a bus. Buses in general have several disadvantages including its scalability and also contention, which is also mentioned in the paper. Thus, changing to a cross bar has it obvious advantages that now multiple packets and request can be forwarded to the outputs at the same time, thus increasing the bandwidth of the backplane. The paper then went on to explain the different design areas of a switched network.
Since i don't have much background on router designs, it's hard for me to comment on this paper. But it seems like since i started studying routers, what i learned was that the interconnect between input and output was a cross bar. Thus, i was quite shocked to hard that it used to be a single bus connecting everything. However, multicast does seem like it would be easier to do on a single bus, because i could imagine all of the outputs seeing the broadcast at the same time since they are all on the same bus. But as we move towards higher speed networks and domains, routers need to be able to support and keep up with the network.
Since i don't have much background on router designs, it's hard for me to comment on this paper. But it seems like since i started studying routers, what i learned was that the interconnect between input and output was a cross bar. Thus, i was quite shocked to hard that it used to be a single bus connecting everything. However, multicast does seem like it would be easier to do on a single bus, because i could imagine all of the outputs seeing the broadcast at the same time since they are all on the same bus. But as we move towards higher speed networks and domains, routers need to be able to support and keep up with the network.
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.
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.
Fundamental design issues for the future internet
This was a very interesting paper to read. It seems that now the internet is well received, and the amount of users are growing by the day, it's hard to imagine any change in the fundamental design of internet. Most of us are used to the way things are, the TCP protocols and the IP and Ethernet designs that we often are blinded to the so called "issues" of the ethernet. This is also an interesting paper to read because for the project for this class our topic was going to be something related to real-time ethernet, or synchronous ethernet, so this was definitely a good intro paper to read.
The paper surveys the design issues of ethernet, defining the quantity V, the efficacy of the architecture, to be used to evaluate different design techniques. It evaluated the efficacy of having separate services on the internet to address different needs. Obviously the current internet architecture has no guarantee of service, delivery, order, or delay when a packet is sent through the internet. However, in the future, with bandwidth and speed both improving, more and more applications will need better services. This paper thus evaluates different design issues of incorporating the different services in one network.
One of the interesting discussions mentioned in this paper is the issue of pricing. I like to think of it also as an issue of security. If there are high priority packets that recieve better bandwidth, why doesn't everyone just use them or abuse them? Of course pricing could be an effective way of preventing regular users from accessing the high priority bandwidth. This would be used with some sort of admission control to limit the and guarantee the services of this reliable network. However, more and more security issues will start to come into play. For example, if a hacker hacks the control system that does the admission control, he could potentially flood the network with high priority packets preventing any other real-time service to be able to gain access to the link etc. This seems like a good topic to do some research on.
The paper surveys the design issues of ethernet, defining the quantity V, the efficacy of the architecture, to be used to evaluate different design techniques. It evaluated the efficacy of having separate services on the internet to address different needs. Obviously the current internet architecture has no guarantee of service, delivery, order, or delay when a packet is sent through the internet. However, in the future, with bandwidth and speed both improving, more and more applications will need better services. This paper thus evaluates different design issues of incorporating the different services in one network.
One of the interesting discussions mentioned in this paper is the issue of pricing. I like to think of it also as an issue of security. If there are high priority packets that recieve better bandwidth, why doesn't everyone just use them or abuse them? Of course pricing could be an effective way of preventing regular users from accessing the high priority bandwidth. This would be used with some sort of admission control to limit the and guarantee the services of this reliable network. However, more and more security issues will start to come into play. For example, if a hacker hacks the control system that does the admission control, he could potentially flood the network with high priority packets preventing any other real-time service to be able to gain access to the link etc. This seems like a good topic to do some research on.
Monday, September 15, 2008
Congestion Control for High Bandwidth-Delay Product Networks
This paper presents a new transport layer protocol called the Explicit Control Protocol (XPC). XPC addresses the problems of TCP where the the bandwidth is underutilized when TCP conservatively controls congestions through slow start and fairness control through the gateways. The proposal for XPC is to use control theory to model the protocol, and decouple the fairness and efficiency control mechanisms used to maintain flexibility and control. However, unlike the previous paper we read where the routers drop packets to control congestion, XPC instead appends a congestion header to all its data packets being sent around. The routers fill out congestion information in the congestion header for those packets and as the packets get routed from destination to destination, the most congested router would be the last to update the packet header, which then the end nodes use to control their sending window.
The XPC router splits efficiency and fairness into two separate algorithms, where as TCP uses the drop packet mechanism to maintain both. This allows the XPC protocol to efficiently use the underused bandwidth when recovering from a congestion slow down. And because it is decoupled from the fairness control, it doesn't have to worry about nodes not getting bandwidth, it just needs to keep the total utilized bandwidth at a high efficiency. The Fairness controller is the one that maintains the bandwidth fairness of the router.
The results of this paper seems to me that is was almost unrealistically good. There were almost no dropped packets, and the performance of the protocol is good when network is un-congested, and also good when the network is congested. Intuitively it seems that because this protocol and gateway doesn't drop packets (intentionally), the quality should be better, and it was built to overcome the flaws of TCP regarding recovery of congestion control mechanisms, thus, its performance can only be better than TCP, while the overhead includes an added packet header for each packet with different control algorithms. It's hard to believe just based on those it can have such a promising results.
The XPC router splits efficiency and fairness into two separate algorithms, where as TCP uses the drop packet mechanism to maintain both. This allows the XPC protocol to efficiently use the underused bandwidth when recovering from a congestion slow down. And because it is decoupled from the fairness control, it doesn't have to worry about nodes not getting bandwidth, it just needs to keep the total utilized bandwidth at a high efficiency. The Fairness controller is the one that maintains the bandwidth fairness of the router.
The results of this paper seems to me that is was almost unrealistically good. There were almost no dropped packets, and the performance of the protocol is good when network is un-congested, and also good when the network is congested. Intuitively it seems that because this protocol and gateway doesn't drop packets (intentionally), the quality should be better, and it was built to overcome the flaws of TCP regarding recovery of congestion control mechanisms, thus, its performance can only be better than TCP, while the overhead includes an added packet header for each packet with different control algorithms. It's hard to believe just based on those it can have such a promising results.
Subscribe to:
Posts (Atom)