Maybe it's bad in research, but I find that I'm a practically-minded guy. I find that I prefer terse papers to some of these 12-14 page ordeals I find in SIGCOMM, etc. Not that they aren't useful, but sometimes it seems like they just take forever to get to the point, requiring a Herculean effort of concentration to see what the problem and their solution is.
My suggestion would be to collectively let go of the stigma of short papers - if somebody did something cool in one page, then let them do it in one page! It could just be that network researchers aren't good at English communication, but I believe that's something that can be learned. We just need to have the drive to. Then again, looking at my own blog posts, maybe I need to worry about the beam in my own eye!
Friday, September 24, 2010
I read this paper for my Applications paper in our networking class, and I was struck by the difference in approach that applications research could take compared with what our last area, architecture, could do. They were able to create an add-on for a popular BitTorrent client that would allow them to use real peers for their research, giving them a large test base practically overnight and giving the peers the benefits of the research instantly. What a great situation to do research in! If only there were some way for architecture to be able to get "buy-in" from network users so easily...
Saturday, September 18, 2010
DNS for people
We read a lot of papers that want to change the way naming on the Internet works, Often the goal seems to be to allow users to connect just to another user, no matter where they are. I think it would be interesting to try some kind of mapping from unique identifiers of devices (MAC addresses, perhaps) to a user entity on the network, such that packets for that user are broadcast to all registered devices on the network. This may have been done (I'm still without Internet access as I write this), but it is something to think about. Registration would require a centralized or semi-centralized solution (super-peers) because flooding the network with requests just gets to be too much for most networks. Target devices could respond with either “don't talk to me, I'm not in use” or with the expected responses to a given packet.
The next question is whether this is more or less efficient than our current DNS setup. That will require research. I find, however, that with services like Google Voice, there does appear to be a demand for such a user location service (location on the network, at least – it might be nice to prevent system abuse by stalkers).
Peer-to-peer networking
Does anyone know if a distributed (peer-to-peer) file system has been proposed as a form of file version control? It seems like that would be a nice way to have both redundant backup as well as reduce reliance on a trunk server. I'd research this more, but I'm cut off from Internet access at the moment, so I'll just describe what I think would be cool at a high level:
Versioned files could be stored and tracked via Gnutella-like super peers, none of which would need to contain the entire trunk, but they COULD have redundancy if it was desired. Deltas seem like they'd be trivial to include in the hierarchy, and thus you'd have a full versioning system distributed across your network.
Saturday, September 11, 2010
What usage should Internet architecture focus on?
Internet architecture research aims to improve the infrastructure of the Internet, but with respect to what? I think most would say that we should meet the most common needs, both current and foreseen, but on thinking about what those needs are, it seems that even that is a difficult question.
Accesses to given services may be a good measure, but improving the network's ability to serve small content fast may harm services that transfer large amounts of data, such as video or possibly gaming. Well-intentioned efforts in enabling easier network research may cause difficulties for those pursuing network security. The ever-present problem of network architecture research is, then, the inherent alteration of the status quo for every endeavor, field, or application built on the current architecture. While we can (and, I think, should) try and minimize the impact that architecture changes would have on current usage, the fact of the matter is that to do anything very meaningful with such a fundamental change as architecture, adaptations will needed at every level of the current architecture. This may be why changes to the way we use the Internet happen incrementally - too much resistance to universally disruptive change. Testing issues make network architecture research difficult; implementation issues threaten to make it prohibitively impractical.
Accesses to given services may be a good measure, but improving the network's ability to serve small content fast may harm services that transfer large amounts of data, such as video or possibly gaming. Well-intentioned efforts in enabling easier network research may cause difficulties for those pursuing network security. The ever-present problem of network architecture research is, then, the inherent alteration of the status quo for every endeavor, field, or application built on the current architecture. While we can (and, I think, should) try and minimize the impact that architecture changes would have on current usage, the fact of the matter is that to do anything very meaningful with such a fundamental change as architecture, adaptations will needed at every level of the current architecture. This may be why changes to the way we use the Internet happen incrementally - too much resistance to universally disruptive change. Testing issues make network architecture research difficult; implementation issues threaten to make it prohibitively impractical.
Thursday, September 9, 2010
Side-by-side network testing
I was reading a whitepaper on an idea called OpenFlow. In short, it's a proposed specification to allow campus networks to run both traditional and experimental architecture side-by-side, allowing researchers to experiment with real data in real networks while not disrupting normal users'...well, usage. They focused on experiments with traffic controlled by one researcher, but I believe this could be expanded.
It looks like the OpenFlow switch could be configured to replicate traffic on the production network. If this is the case (and the traffic in question is not sensitive/whatever other privacy concerns there be are addressed), it seems like it shouldn't be too difficult to set up a replica network with virtual users. A few more powerful machines (each representing a number of actual and potential users) could be dedicated to simulating the same traffic that occurs on the production network and thus help determine how an experimental protocol or architecture idea would perform in the real world. What could be a better test than real data?
It looks like the OpenFlow switch could be configured to replicate traffic on the production network. If this is the case (and the traffic in question is not sensitive/whatever other privacy concerns there be are addressed), it seems like it shouldn't be too difficult to set up a replica network with virtual users. A few more powerful machines (each representing a number of actual and potential users) could be dedicated to simulating the same traffic that occurs on the production network and thus help determine how an experimental protocol or architecture idea would perform in the real world. What could be a better test than real data?
Saturday, September 4, 2010
Briefly on Internet Architecture Research
I've been thinking about the motivation for Internet architecture research, and why it seems that no for-profit companies are terribly interested in it right now (at least not compared with NSF, etc.). Most of us tend not to replace the car until it's becoming pretty clear that it needs replacing; parts break (frequently) or it fails to meet changing needs (the curse of the minivan for young families). I think that at the moment, our current Internet architecture tends to meet the needs of users reliably, and thus few entities are willing to fund research into changing that working architecture.
We probably shouldn't condemn anybody for not wanting to fix what ain't broke, but I am glad that there is research going on in a seemingly unwanted area. At some point, there will be breakage (I'm thinking due to problems of scale) or changing needs, which I'm not going to even try to predict. We're already working on the problems we can foresee, and I believe that the experience and knowledge gained will be useful in helping us cope with new and unforeseen demands as well. For instance, we have discovered that testing new network architecture ideas on a large scale is difficult -- networks that big tend to get annoyingly useful to somebody who will complain if the experiment fails and the network is down for a while. Thus we have research in the style of DONA, using techniques that will allow us to use parts of existing architecture to make any necessary transition as painless as possible.
In summation, I quote the Heavy Weapons Guy: "Good job, everyone!"
We probably shouldn't condemn anybody for not wanting to fix what ain't broke, but I am glad that there is research going on in a seemingly unwanted area. At some point, there will be breakage (I'm thinking due to problems of scale) or changing needs, which I'm not going to even try to predict. We're already working on the problems we can foresee, and I believe that the experience and knowledge gained will be useful in helping us cope with new and unforeseen demands as well. For instance, we have discovered that testing new network architecture ideas on a large scale is difficult -- networks that big tend to get annoyingly useful to somebody who will complain if the experiment fails and the network is down for a while. Thus we have research in the style of DONA, using techniques that will allow us to use parts of existing architecture to make any necessary transition as painless as possible.
In summation, I quote the Heavy Weapons Guy: "Good job, everyone!"
Thursday, September 2, 2010
DONA
Having read "A Data-Oriented (and Beyond) Network Architecture" from the 2007 SIGCOMM, I am both intrigued and skeptical about the idea. Intrigued because I think this could be an interesting way to route data over a network and avoid connection loss, but a bit skeptical because I fear the increased complexity for the user may prevent its adoption. Granted, these may be somewhat naive thoughts, but here they are anyway:
From the article: "Today, however, the vast majority of Internet usage is data
retrieval and service access, where the user cares about content
and is oblivious to location. That is, the user knows that she wants
headlines from CNN, or videos from YouTube, or access to her
bank account, but does not know or care on which machine the
desired data or service resides." This is true; the users, by and large, just want to get at the content their interested in, wherever it resides. One could probably extend this mindset and say that the users just want to have an easy way to get to content.
The problem I see is briefly addressed later in the paper:
"...How will users learn these
flat, long, and user-unfriendly names? We expect that users will
learn these flat names through a variety of external mechanisms that
the user trusts... Users won’t,
of course, remember the flat names directly, but will have their own
private namespace of human-readable names, which map onto these
global and flat names... While such flat names are harder
to use than today’s DNS names, they offer the advantage that the
mappings between private human-readable names and flat names
will be free to reflect evolving social structures rather than being
tied, as DNS names are, to a fixed administrative structure."
If the user is required to put more effort into managing oft-frequented sites, I believe there would be some more resistance to the use of this system, at least until something that sounds similar to DNS is implemented - a large, standard mapping of human-readable names to flat names. The problem there is that we're back to the very problem that DONA was trying to solve! I believe that as an architectural improvement, DONA could be quite valuable, but I fear that their apparent desire to replace DNS could not be realized because a less technically-sophisticated public would demand convenience. I am reminded of "Why Johnny Can't Encrypt," by Whitten and Tygar, where a user study found that PGP encryption was not widely adopted because of increased end-user complexity. Users, in the end, want networks to function with a minimum of input from their end, and I believe there would be a great deal of resistance to a change that increased the effort required of those users.
[As an aside: I really hate when people switch the misperceived-as-sexist-but-grammatically-gender-neutral "he" for the most-assuredly-sexist-but-in-the-nonstandard-way "she." Maybe I'll discuss that sometime later.]
From the article: "Today, however, the vast majority of Internet usage is data
retrieval and service access, where the user cares about content
and is oblivious to location. That is, the user knows that she wants
headlines from CNN, or videos from YouTube, or access to her
bank account, but does not know or care on which machine the
desired data or service resides." This is true; the users, by and large, just want to get at the content their interested in, wherever it resides. One could probably extend this mindset and say that the users just want to have an easy way to get to content.
The problem I see is briefly addressed later in the paper:
"...How will users learn these
flat, long, and user-unfriendly names? We expect that users will
learn these flat names through a variety of external mechanisms that
the user trusts... Users won’t,
of course, remember the flat names directly, but will have their own
private namespace of human-readable names, which map onto these
global and flat names... While such flat names are harder
to use than today’s DNS names, they offer the advantage that the
mappings between private human-readable names and flat names
will be free to reflect evolving social structures rather than being
tied, as DNS names are, to a fixed administrative structure."
If the user is required to put more effort into managing oft-frequented sites, I believe there would be some more resistance to the use of this system, at least until something that sounds similar to DNS is implemented - a large, standard mapping of human-readable names to flat names. The problem there is that we're back to the very problem that DONA was trying to solve! I believe that as an architectural improvement, DONA could be quite valuable, but I fear that their apparent desire to replace DNS could not be realized because a less technically-sophisticated public would demand convenience. I am reminded of "Why Johnny Can't Encrypt," by Whitten and Tygar, where a user study found that PGP encryption was not widely adopted because of increased end-user complexity. Users, in the end, want networks to function with a minimum of input from their end, and I believe there would be a great deal of resistance to a change that increased the effort required of those users.
[As an aside: I really hate when people switch the misperceived-as-sexist-but-grammatically-gender-neutral "he" for the most-assuredly-sexist-but-in-the-nonstandard-way "she." Maybe I'll discuss that sometime later.]
Subscribe to:
Posts (Atom)