One of the things I am taking away from this class is what I have learned about writing a good research paper. We have read alot of papers, reported on them to the class, asked and answered questions about them. Throughout the semester Dr. Zappala has pointed out aspects of good writing, which has been very helpful. He has especially commented on what makes an introduction useful.
He has taught us how to find new papers, how to break into new research areas on our own. He has taught us, through the activities of this class, how to separate a research area into parts, how to begin to comprehend the parts and their relationship to whole. I have learned a lot about networking, but perhaps more importantly I have learned a lot about writing and research.
The interactive format of the class has been very productive and fun. Having the consistent experience of presenting papers to each other was, I thought, a great use of class time. The instructor jumped in to help us a lot, but that was much better than being left out of the teaching experience. We really do learn by doing.
Saturday, December 18, 2010
Think by Writing
I am the polar opposite of a blogger. So why am I blogging? Because it is required for this class. I must admit it may have been a good experience. I have used this blog as an opportunity to think about a lot of different things relating to computer networking. Writing about my thoughts has helped me to think more clearly. I know that this is a well understood principle, but it really has helped me. Blogging throughout the semester helped me to formulate the ideas leading to my research proposal, just submitted at the end of the semester.
Writing isn't my favorite activity; talking is much easier for me. All this writing is probably making writing easier, and perhaps more enjoyable. See, look at me, I'm blabbering on and on to an invisible audience. Save yourself. Please stop reading now while you can. If you are still reading one of two things might be true. Either I have become really good at blogging, or you are putting together my grade for this class.
Writing isn't my favorite activity; talking is much easier for me. All this writing is probably making writing easier, and perhaps more enjoyable. See, look at me, I'm blabbering on and on to an invisible audience. Save yourself. Please stop reading now while you can. If you are still reading one of two things might be true. Either I have become really good at blogging, or you are putting together my grade for this class.
Tuesday, December 14, 2010
Deployment, Deployment, Deployment
A major recurring theme in my study of computer networking is overcoming barriers to deployment. It seems that just about every proposal must address this issue.
By design, the Internet is something that everyone can use. It is the network of networks. The primary objective which motivated the original design of the Internet was to tie all types of different networks together into one network. Since the Internet is designed for such universal use, it is a special challenge to deploy any sort of substantive change.
Any change which might break compatibility of systems currently communicating over the Internet faces a steep uphill battle, no matter how green the grass might be on the other side. It seems that improvements do come, but require some sort of non-disruptive deployment path.
Deployment tends to be the domain of engineers, rather than researchers. However, it seems to me that deployment is central to research in this field.
By design, the Internet is something that everyone can use. It is the network of networks. The primary objective which motivated the original design of the Internet was to tie all types of different networks together into one network. Since the Internet is designed for such universal use, it is a special challenge to deploy any sort of substantive change.
Any change which might break compatibility of systems currently communicating over the Internet faces a steep uphill battle, no matter how green the grass might be on the other side. It seems that improvements do come, but require some sort of non-disruptive deployment path.
Deployment tends to be the domain of engineers, rather than researchers. However, it seems to me that deployment is central to research in this field.
Additional Header Information
Headers are used to convey certain information about a packet. There are situations where additional information might be helpful, beyond that originally provided in the header.
One example of providing additional header information is explicit congestion notification. Routers mark headers with congestion information which can then be used by senders to avoid congesting the network.
Another example is NetFence. In this proposed solution to the problem of DoS attacks, a special NetFence header is inserted between the IP and TCP headers. The purpose of this header is to facilitate communication between routers and hosts, aimed at minimizing damage from malicious hosts.
In these examples, problems related to congestion and security are addressed by adding information to packet headers as they travel through the network. This is an observation that is interesting to me. I am seeing headers as more than just a place to store static information, but rather has a means for routers and hosts to communicate with each other regarding the packets they are transporting.
One example of providing additional header information is explicit congestion notification. Routers mark headers with congestion information which can then be used by senders to avoid congesting the network.
Another example is NetFence. In this proposed solution to the problem of DoS attacks, a special NetFence header is inserted between the IP and TCP headers. The purpose of this header is to facilitate communication between routers and hosts, aimed at minimizing damage from malicious hosts.
In these examples, problems related to congestion and security are addressed by adding information to packet headers as they travel through the network. This is an observation that is interesting to me. I am seeing headers as more than just a place to store static information, but rather has a means for routers and hosts to communicate with each other regarding the packets they are transporting.
Smart 'Middles'
NetFence, discussed in class, is a proposed solution to the problem of DoS attacks. It departs from previous work in that it places the 'middle' in the first line of defense against these types of attacks, rather than the 'ends'.
We have already learned that the 'middle' has access to important information that can be very difficult for the 'ends' to infer. For example, the total number of flows at a bottleneck link and the capacity of that link. This type of information is easily accessible at the bottleneck router, but can be very inaccessible to the affected senders. Such information can make it possible for senders to avoid congestion.
Security is yet another concern which demonstrates the need for smart 'middles'. This is all interesting in light of the end-to-end principle. This principle might be interpreted as stating that the 'middle' should not be replicating work which is better done at the 'ends'. However, there is significant work that the 'ends' are ill-equipped to do.
If, as discussed in NetFence, a sender and receiver collude to overwhelm a link, the 'ends' are both malicious and the target of the attack is the 'middle' itself. Certainly in such a case, initiative is needed in the 'middle'.
We have already learned that the 'middle' has access to important information that can be very difficult for the 'ends' to infer. For example, the total number of flows at a bottleneck link and the capacity of that link. This type of information is easily accessible at the bottleneck router, but can be very inaccessible to the affected senders. Such information can make it possible for senders to avoid congestion.
Security is yet another concern which demonstrates the need for smart 'middles'. This is all interesting in light of the end-to-end principle. This principle might be interpreted as stating that the 'middle' should not be replicating work which is better done at the 'ends'. However, there is significant work that the 'ends' are ill-equipped to do.
If, as discussed in NetFence, a sender and receiver collude to overwhelm a link, the 'ends' are both malicious and the target of the attack is the 'middle' itself. Certainly in such a case, initiative is needed in the 'middle'.
Thursday, December 9, 2010
Bufferbloat and TCP Performance
I ran into two articles by Jim Gettys, entitled The criminal mastermind: bufferbloat and Whose house is of glasse, must not throw stones at another. In a nutshell, the point is that operating systems, home routers, cable modems, etc. are buffering too much data, which hurts the performance of TCP because it doesn't get notification of congestion. His results show that the performance effects of poorly tuned buffer sizes are dramatic and widespread. It's an interesting read.
Security and Laziness
I read that Morris had suggested the theoretical possibility of an Initial Sequence Number attack in Bell Labs Computer Science Technical Report #117, February 25, 1985. In 1995, Kevin Mitnick carried out this attack (described in Tsutomu Shimomura's book Takedown and in many other resources online). I find it very interesting that security problems so often go unfixed until after they're exploited.
I had this experience once as a system administrator in the CS department. I had noticed that a course's submission system was insecure and that students could steal from and/or overwrite other students' submissions. I emailed the professor about this in November 2003 and again in February 2004 when the problem still had not been fixed. In March 2005, a student was caught cheating, and it turned out that the student had exploited the security problem that I had reported more than a year earlier. If the professor had taken half an hour to carry out the single-command fix that I had proposed, then this student may not have cheated.
Another recent example of this is website encryption. For years, it has been common knowledge that unencrypted HTTP sessions can be hijacked. However, almost no major websites used SSL by default. Finally, Firesheep made people realize that this was a real problem (even though it had already been a real problem for years earlier). Somehow, people feel justified in ignoring security problems if they think the exploit sounds hard or unlikely, even if it is neither.
I had this experience once as a system administrator in the CS department. I had noticed that a course's submission system was insecure and that students could steal from and/or overwrite other students' submissions. I emailed the professor about this in November 2003 and again in February 2004 when the problem still had not been fixed. In March 2005, a student was caught cheating, and it turned out that the student had exploited the security problem that I had reported more than a year earlier. If the professor had taken half an hour to carry out the single-command fix that I had proposed, then this student may not have cheated.
Another recent example of this is website encryption. For years, it has been common knowledge that unencrypted HTTP sessions can be hijacked. However, almost no major websites used SSL by default. Finally, Firesheep made people realize that this was a real problem (even though it had already been a real problem for years earlier). Somehow, people feel justified in ignoring security problems if they think the exploit sounds hard or unlikely, even if it is neither.
Security for Internet Routing
So far, I haven't heard much about secure routing protocols. As I mentioned in an earlier post, BGP is vulnerable to both mistakes and attacks. I recently came across a statement on RPKI from the Internet Architecture Board (IAB). The statement seemed fairly vague technically, but they seemed to be saying that using public key cryptography to secure routing protocols should be a high priority. Of course, I don't know whether statements from the IAB are common nor whether they carry much weight.
Wikipedia has a very short article on RPKI, which only said that it is in some stage of the standardization process. The most detailed information I have found is a brief RPKI summary on the APNIC site. It would be interesting to learn more about what security systems have been proposed for routing and which of them seem to be moving forward.
Wikipedia has a very short article on RPKI, which only said that it is in some stage of the standardization process. The most detailed information I have found is a brief RPKI summary on the APNIC site. It would be interesting to learn more about what security systems have been proposed for routing and which of them seem to be moving forward.
Tuesday, November 30, 2010
Last-Mile Monopolies
ArsTechnica recently reported on how Comcast is indirectly charging Netflix in preferential treatment to its own IPTV service. The report has the colorful title How Comcast became a toll-collecting, nuke-wielding hydra.
In a nutshell (as far as I understand it), Comcast has a customer relationship with L3 Communications, a top-tier network. Since Comcast has so many customers, they have not traditionally had to pay L3 for their connection. In the meantime, L3 has been building a CDN business, and Netflix (the number one source of bandwidth on the Internet) is now using this CDN service. Comcast, whose customers are paying $50 per month for their Internet connections, are now charging L3 to fulfill these customers' requests to Netflix.
In other words, these people are not just paying Comcast for their Internet connection and Netflix for their movies, but they are now also paying Netflix to pay L3 to pay Comcast for their Internet connection again. Since Comcast is a last-mile monopoly, neither their customers nor service providers have any practical recourse.
Of course, customers don't currently see any of this. My suggestion is for Netflix to charge more per month for Comcast customers than for anyone else. Not only would this keep other Netflix customers from having to foot the bill, but it would also help Comcast's customers understand what is going on. Those few who have the option of switching to a different ISP can do so, and the others can become proponents of network neutrality legislation.
In a nutshell (as far as I understand it), Comcast has a customer relationship with L3 Communications, a top-tier network. Since Comcast has so many customers, they have not traditionally had to pay L3 for their connection. In the meantime, L3 has been building a CDN business, and Netflix (the number one source of bandwidth on the Internet) is now using this CDN service. Comcast, whose customers are paying $50 per month for their Internet connections, are now charging L3 to fulfill these customers' requests to Netflix.
In other words, these people are not just paying Comcast for their Internet connection and Netflix for their movies, but they are now also paying Netflix to pay L3 to pay Comcast for their Internet connection again. Since Comcast is a last-mile monopoly, neither their customers nor service providers have any practical recourse.
Of course, customers don't currently see any of this. My suggestion is for Netflix to charge more per month for Comcast customers than for anyone else. Not only would this keep other Netflix customers from having to foot the bill, but it would also help Comcast's customers understand what is going on. Those few who have the option of switching to a different ISP can do so, and the others can become proponents of network neutrality legislation.
Monday, November 29, 2010
Research is Cheating?
I recently read a blog post entitled Google and Microsoft Cheat on Slow-Start. Should You?. The article points out that Google has an initial congestion window of 9 packets, and Microsoft's value is even larger, while most websites have a value between 2 or 4. All of this is interesting, but the article goes on to accuse Google and Microsoft of "cheating," citing a "violation" of RFC 3390. Although the tone of RFC 3390 does seem to encourage this sort of reaction, I think that this is an unfortunate attitude.
First, we should be encouraging people to develop protocols, not to keep them stagnant. Holding strictly to decade-old values (4 KB initial windows were proposed in 1998) does not necessarily do anyone any favors. RFC 3390 mentions that this particular value of 4 KB was tested and found to not cause additional congestion on a "28.8 bps dialup channel." Twelve years later, when most Americans have links that are orders of magnitude faster, shouldn't this be reconsidered?
Second, I am bothered by the use of the word "cheating," which implies that a larger initial congestion window would help the perpetrator to the detriment of all other users. Although this may be true over some specific link, in general web sites are motivated to pick a good value. If the value is unnecessarily low, than web pages load too slowly, and if it is too high, then web pages also load too slowly (due to dropped packets). If web sites are trying to pick the optimal value, should this be considered cheating?
I think we should try to foster an attitude that is positive toward experimenting with improvements to Internet Protocols as long as they retain backwards compatibility and don't risk causing catastrophic problems.
First, we should be encouraging people to develop protocols, not to keep them stagnant. Holding strictly to decade-old values (4 KB initial windows were proposed in 1998) does not necessarily do anyone any favors. RFC 3390 mentions that this particular value of 4 KB was tested and found to not cause additional congestion on a "28.8 bps dialup channel." Twelve years later, when most Americans have links that are orders of magnitude faster, shouldn't this be reconsidered?
Second, I am bothered by the use of the word "cheating," which implies that a larger initial congestion window would help the perpetrator to the detriment of all other users. Although this may be true over some specific link, in general web sites are motivated to pick a good value. If the value is unnecessarily low, than web pages load too slowly, and if it is too high, then web pages also load too slowly (due to dropped packets). If web sites are trying to pick the optimal value, should this be considered cheating?
I think we should try to foster an attitude that is positive toward experimenting with improvements to Internet Protocols as long as they retain backwards compatibility and don't risk causing catastrophic problems.
Tuesday, November 23, 2010
Minimum Loss
The paper "Routing Metrics and Protocols for Wireless Mesh Networks" explores the utility of various routing metrics. I was particularly interested in minimum loss (ML). It is interesting because of its simplicity, its performance, and its relationship to probability theory.
It is a simple metric, very much like expected transmission count (ETX). In the paper, the performance of ETX, ML, and two other metrics are compared. Performance was measured in four ways: Number of hops, loss rate, RTT, and throughput. ML consistently led to the highest number of hops, yet the lowest loss.
Throughput was measured from a starting node to each of the other mesh nodes in the network. For all metrics, there was a sharp drop off in throughput for all nodes which were more than one hop away from the starting node. It was interesting to me that this drop was much less pronounced for ML. The drop off curve for ML was much smoother. Throughput using ML for nodes two hops away from the starting node was about twice that of throughput using all other metrics.
The key difference between ETX and ML is multiplication as opposed to addition. When calculating ETX over multiple hops, total ETX is the sum of ETX for each hop. When calculating ML, total loss is the product of losses for each hop. It is interesting to me that the multiplication approach is similar to what is done in probability theory. Total probability of independent events is the product of each of the individual events.
It is a simple metric, very much like expected transmission count (ETX). In the paper, the performance of ETX, ML, and two other metrics are compared. Performance was measured in four ways: Number of hops, loss rate, RTT, and throughput. ML consistently led to the highest number of hops, yet the lowest loss.
Throughput was measured from a starting node to each of the other mesh nodes in the network. For all metrics, there was a sharp drop off in throughput for all nodes which were more than one hop away from the starting node. It was interesting to me that this drop was much less pronounced for ML. The drop off curve for ML was much smoother. Throughput using ML for nodes two hops away from the starting node was about twice that of throughput using all other metrics.
The key difference between ETX and ML is multiplication as opposed to addition. When calculating ETX over multiple hops, total ETX is the sum of ETX for each hop. When calculating ML, total loss is the product of losses for each hop. It is interesting to me that the multiplication approach is similar to what is done in probability theory. Total probability of independent events is the product of each of the individual events.
The Central Role of Routing
It seems to me that routing plays a central role in almost every area of computer networking. It is such a central part of networking that I suppose it is fair to say that routing is the core of networking. Certainly routers are at the physical core of networks.
Transport is distinct from routing. Our study of transport centered on congestion control. Congestion happens at routers. Congestion is essentially a clogged route. The most effective congestion control schemes make use of explicit congestion feedback from routers.
Much of what we studied in the application space had to do with locating distributed content, which can also be seen as a routing problem. Perhaps this is a stretch, but the big picture is that applications are being used to find a better path for content delivery.
Our study of Internet architecture focused on naming and addressing. Names and addresses are for routing. Our study of wireless has been dominated by routing challenges specific to the wireless environment.
We started this class with the end-to-end principle. What is the middle? It is the network. What is a network? Isn't it essentially routing?
Transport is distinct from routing. Our study of transport centered on congestion control. Congestion happens at routers. Congestion is essentially a clogged route. The most effective congestion control schemes make use of explicit congestion feedback from routers.
Much of what we studied in the application space had to do with locating distributed content, which can also be seen as a routing problem. Perhaps this is a stretch, but the big picture is that applications are being used to find a better path for content delivery.
Our study of Internet architecture focused on naming and addressing. Names and addresses are for routing. Our study of wireless has been dominated by routing challenges specific to the wireless environment.
We started this class with the end-to-end principle. What is the middle? It is the network. What is a network? Isn't it essentially routing?
Friday, November 19, 2010
More on the Economics of Net Neutrality
I ran into a blog today by a telco analyst. His posts give a different perspective on the net neutrality debate. One of the most interesting posts I saw was A Grave of Their Own Making which uses a back-of-the-envelope calculation to estimate that Google probably makes about $1 per month per customer. His point is that it's not actually worth it to the ISPs to try to charge Google money to access their customers because even if Google paid it wouldn't be much money. Of course, if Google decided not to pay and an ISP cut off the service, the ISP would lose more money for each customer that left than Google would lose for 35 customers who stayed with the ISP and got cut off.
Another post, The Slow Suicide of Net Discrimination summed up this point and a few other arguments by the author to show that ISPs really shouldn't waste their time worrying about net neutrality. The author made some interesting points that I hadn't thought about before.
Another post, The Slow Suicide of Net Discrimination summed up this point and a few other arguments by the author to show that ISPs really shouldn't waste their time worrying about net neutrality. The author made some interesting points that I hadn't thought about before.
Tuesday, November 16, 2010
Tracking Down Real-life Problems with Wireshark
This summer, our only Internet access was using Google WiFi. If you aren't familiar with it, Google WiFi is a network of wireless routers on streetlight poles scattered throughout the city. It's a great idea, and it has the opportunity to be a great service, but we had terrible experiences. Occasionally we could successfully browse the web for about 15 minutes, but more often, our average load time for a page was about 30 seconds. It was not uncommon for connections to timeout repeatedly, and there were times when I spent more than 60 minutes trying to use a single website. All in all, it was a pretty awful system.
A few times, I tried to figure out why Google WiFi was so bad. Unfortunately, as the user of a complex system like this, there are too many possible sources of problems, and there isn't enough information available. However, I had some success in tracking down one particular problem.
We noticed that the connection was particularly awful when Google WiFi required us to reauthenticate by redirecting us to a login screen. It was occasionally difficult to realize that this was happening because the system attempted to transparently redirect to the login page, check our cookie, and then transparently redirect back to the page we requested. I think this was only supposed to happen once a day, but there are times when I noticed it 3 or 4 times within an hour. And although this process was supposed to be instantaneous, it usually took about 10 minutes to authenticate because pages would timeout. I decided to use Wireshark to try to figure out what was happening, and I found a horrible configuration error on Google's part. I noticed that when my browser was redirected to Google's login page that it would create a bunch of DNS requests for hosts like "ocsp.thawte.com". The browser would then connect to these hosts and receive an HTTP response redirecting to Google's authentication page. Looking up "OCSP", I learned that this was an SSL certificate revocation protocol, and I realized that my browser was trying to verify Google's certificate, but that these OCSP requests were getting intercepted and redirected by Google's firewall because we weren't authenticated yet. But the browser couldn't authenticate because the OCSP requests were getting redirected. This dance could continue for a long time. Anyway, I reported this problem on Google's WiFi forum, and who knows if they ever dealt with it. As a user, I got the feeling that free WiFi was probably the lowest priority project in the company.
Wireshark was able to help me track down one problem, but I'm not aware of any great tools for diagnosing other instances of dropped traffic. I couldn't tell whether packets were getting dropped in the air between our computer and the closest router, or during wireless transmission to further upstream routers, or at some higher protocol level (as with the OCSP problem). In the end, I came to the conclusion that we would have been better off without Google WiFi, as it wasted many hours of our life; we could have avoided this in advance if we had known how bad it would be. Unfortunately, if even Google can't make wireless mesh networks work, I have my doubts that the technology is ready yet. For all of the exciting promises of wireless, I can't say that it "just works" like wired networks usually seem to.
A few times, I tried to figure out why Google WiFi was so bad. Unfortunately, as the user of a complex system like this, there are too many possible sources of problems, and there isn't enough information available. However, I had some success in tracking down one particular problem.
We noticed that the connection was particularly awful when Google WiFi required us to reauthenticate by redirecting us to a login screen. It was occasionally difficult to realize that this was happening because the system attempted to transparently redirect to the login page, check our cookie, and then transparently redirect back to the page we requested. I think this was only supposed to happen once a day, but there are times when I noticed it 3 or 4 times within an hour. And although this process was supposed to be instantaneous, it usually took about 10 minutes to authenticate because pages would timeout. I decided to use Wireshark to try to figure out what was happening, and I found a horrible configuration error on Google's part. I noticed that when my browser was redirected to Google's login page that it would create a bunch of DNS requests for hosts like "ocsp.thawte.com". The browser would then connect to these hosts and receive an HTTP response redirecting to Google's authentication page. Looking up "OCSP", I learned that this was an SSL certificate revocation protocol, and I realized that my browser was trying to verify Google's certificate, but that these OCSP requests were getting intercepted and redirected by Google's firewall because we weren't authenticated yet. But the browser couldn't authenticate because the OCSP requests were getting redirected. This dance could continue for a long time. Anyway, I reported this problem on Google's WiFi forum, and who knows if they ever dealt with it. As a user, I got the feeling that free WiFi was probably the lowest priority project in the company.
Wireshark was able to help me track down one problem, but I'm not aware of any great tools for diagnosing other instances of dropped traffic. I couldn't tell whether packets were getting dropped in the air between our computer and the closest router, or during wireless transmission to further upstream routers, or at some higher protocol level (as with the OCSP problem). In the end, I came to the conclusion that we would have been better off without Google WiFi, as it wasted many hours of our life; we could have avoided this in advance if we had known how bad it would be. Unfortunately, if even Google can't make wireless mesh networks work, I have my doubts that the technology is ready yet. For all of the exciting promises of wireless, I can't say that it "just works" like wired networks usually seem to.
Reconsidering Assumptions
We recently read a paper about network coding in wireless networks. Not only was this an amazingly clever idea, but it also serves as a reminder of the importance of reconsidering assumptions (or conventional wisdom). Great effort has gone into building protocols on top of antenna-based communications to try to make this awkward, noisy broadcast medium as much like wired networks as possible. The wireless coding paper is particularly significant because the authors stepped back and considered whether there might be any advantages to using a broadcast medium.
I've always been something of a wireless skeptic. I appreciate the convenience and flexibility of wireless communications, but I've been frustrated by their slowness and unreliability. Because of this attitude, I'm a person who would never have come up with the network coding idea. Anyway, it's important to have an open mind and to consider whether a problem might have hidden strengths in addition to the obvious challenges.
I've always been something of a wireless skeptic. I appreciate the convenience and flexibility of wireless communications, but I've been frustrated by their slowness and unreliability. Because of this attitude, I'm a person who would never have come up with the network coding idea. Anyway, it's important to have an open mind and to consider whether a problem might have hidden strengths in addition to the obvious challenges.
Routing Security
It's been a few weeks since our routing section, and in a few more weeks we'll get to security. Since we're right in the middle, it seems like a good time to mention security in the context of routing.
We all know that BGP has problems with scalability and reliability, but I usually haven't focused on the security implications. It turns out that a malicious telecommunications company could cause some pretty serious problems. On April 8, 2010, BGPmon reported an incident where China Telecom "originated about ~37,000 unique prefixes that are not assigned to them" for about 15 minutes. Such incidents are fairly common in that a few times a year, some ISP causes disruption to large portions of the Internet. However, this situation was different because traffic moved through China Telecom's routers without being dropped. If an event like this were carried out intentionally, it could result in tremendous damage to individual, corporate, or national security.
We all know that BGP has problems with scalability and reliability, but I usually haven't focused on the security implications. It turns out that a malicious telecommunications company could cause some pretty serious problems. On April 8, 2010, BGPmon reported an incident where China Telecom "originated about ~37,000 unique prefixes that are not assigned to them" for about 15 minutes. Such incidents are fairly common in that a few times a year, some ISP causes disruption to large portions of the Internet. However, this situation was different because traffic moved through China Telecom's routers without being dropped. If an event like this were carried out intentionally, it could result in tremendous damage to individual, corporate, or national security.
Monday, November 15, 2010
You Gotta Love It
Several papers we have studied apply theoretical results from related fields to the solution of practical problems in computer networking. Examples of this are the application of consistent hashing in Chord, the application of network coding in COPE, and the application of cooperative diversity in ExOR.
Generally, I think this sort of thing can be very productive, because it leverages work which has already been done. In order to do this sort of thing it is necessary for researchers in one field to be aware of work done in other fields. Particularly, it is important for researchers in applied fields to be abreast of work in theoretical fields.
I think that can be challenging, to stay abreast of theoretical work going on in related disciplines. It's challenging enough just to stay abreast of your own field. I suppose that is why it is important for researchers to love to read and learn about other people's work, because there is so much of that to do.
Generally, I think this sort of thing can be very productive, because it leverages work which has already been done. In order to do this sort of thing it is necessary for researchers in one field to be aware of work done in other fields. Particularly, it is important for researchers in applied fields to be abreast of work in theoretical fields.
I think that can be challenging, to stay abreast of theoretical work going on in related disciplines. It's challenging enough just to stay abreast of your own field. I suppose that is why it is important for researchers to love to read and learn about other people's work, because there is so much of that to do.
Friday, November 12, 2010
An Ever Darkening World
One thing that we haven't studied is the effect of malicious users and perverse content on the Internet as a whole. From the beginning the Internet has been plagued with such problems. Now that we have spam filtering for our email, things seem better for me.
In Book of Mormon terms, I wonder how hard we are laboring to support iniquity. President Monson spoke once about prostituting presses. This was in relation to printing pornographic material. Certainly computer networks are being prostituted in a significant way. I wonder to what extent this is happening. What are the trends, compared to legitimate traffic? What are the costs and how are they distributed? What is the effect on society as a whole? Are we winning or losing?
The words of the prophets speak of an every darkening world. As the world collectively descends into the pit of sinful living, I suppose our networks are becoming more corrupt over time. I also suppose that this negative force will eventually threaten the benefits associated with the power of the Internet.
In Book of Mormon terms, I wonder how hard we are laboring to support iniquity. President Monson spoke once about prostituting presses. This was in relation to printing pornographic material. Certainly computer networks are being prostituted in a significant way. I wonder to what extent this is happening. What are the trends, compared to legitimate traffic? What are the costs and how are they distributed? What is the effect on society as a whole? Are we winning or losing?
The words of the prophets speak of an every darkening world. As the world collectively descends into the pit of sinful living, I suppose our networks are becoming more corrupt over time. I also suppose that this negative force will eventually threaten the benefits associated with the power of the Internet.
Network Simulation and Inspection
Omnet Inet and Wireshark are tools I used in our most recent lab. They enabled me to see how a network works at a very fine level of detail. The level of detail even went down to interactions between various OSI layers on a host, and the length of delay on a wire. I found it fascinating. It helped me to better understand how things fit together.
Wireshark is very easy to use. I had a much harder time making sense of the other two tools.
I think it would be interesting to get a hold of some real network traces and analyze them. Real data, rather than simulated, probably has a lot more to say. I would be interested to see what research has been done in the area of inferring characteristics of network traffic from data. Doing so would involve ways to analyze very large amounts of data.
Wireshark is very easy to use. I had a much harder time making sense of the other two tools.
I think it would be interesting to get a hold of some real network traces and analyze them. Real data, rather than simulated, probably has a lot more to say. I would be interested to see what research has been done in the area of inferring characteristics of network traffic from data. Doing so would involve ways to analyze very large amounts of data.
The Great Divide
I was very surprised to learn how different wireless networking is from wired networking. What I expected was to study extensions to what we had already learned which were applicable to wireless. What I learned is that the constraints of wireless motivate drastic changes from the was networking is normally done.
For example, in opportunistic routing for wireless networks an ACK to the sender and new data to the receiver are effectively relayed by some intermediate party in the same message. This is totally different. Another example of the extent of the difference is that routing may be handled to a significant extent below the IP layer, near the MAC.
Another indication of the divide between wired and wireless is that 2 of the 4 papers we have studied so far came from a conference dedicated to mobile computing and wireless.
I expect to see other big differences in the future. I also suspect that much of what I have learned in the context of wired networking may not be very applicable in the context of wireless.
For example, in opportunistic routing for wireless networks an ACK to the sender and new data to the receiver are effectively relayed by some intermediate party in the same message. This is totally different. Another example of the extent of the difference is that routing may be handled to a significant extent below the IP layer, near the MAC.
Another indication of the divide between wired and wireless is that 2 of the 4 papers we have studied so far came from a conference dedicated to mobile computing and wireless.
I expect to see other big differences in the future. I also suspect that much of what I have learned in the context of wired networking may not be very applicable in the context of wireless.
Subscribe to:
Posts (Atom)