Friday, July 20, 2007
Tunneling to Freedom
I recently set up a home server using a beta version of Microsoft Windows Home Server software. Much of the functionality of this product is the automation of the stuff that everyone knows they ought to do but somehow never get around to doing, things like regular backups and organized set of sharable directories. That part was mildly interesting to me, but not all that big a deal. What I was really interested in was making the shared storage available on the Internet.
I have tried to do this in the past. I set up a full SharePoint server at one point and tried to gain access to it remotely. This ran afoul of my ISP's (Cox, as you can tell from my email address) regulated environment, which blocks traffic on TCP port 80 which originates from user systems. This makes sense, given that many users would otherwise set up (or have set up for them, courtesy of malware) public web servers. My goal was simply to set up a more private site for myself, family members, and a few customers.
Granted, I could do this via any number of service providers. This is the way any number of normal people do things like that, but I have rarely been accused of being normal. I have experimented a bit with the user websites that Cox allows as well, but I don't like having relatively arbitrary limits on website sizes or traffic. You can mark these up to me being a control freak or simply being too cheap to pay for the extra service, but one way or another I would just prefer to run this site on my own hardware.
The Microsoft Home Server product allowed me to do that very easily. The default website allows password-protected access to files, as well as remote control access to my home systems. The Cox blocks are bypassed via tunneling technology which effectively shields them from discovering what kind of traffic I am sending across their network. Theoretically I could set up my own porn website, although the sheer volume of traffic would probably tip them off in that case.
So what does all this have to do with embedded systems, you might well ask. The answer involves the design of peer-to-peer network devices and how these devcies can traverse arbitrary portions of the Internet without being blocked by arbitrary rules of the road in any particular segment. This is becoming a concern as routers have begun being more selective as to the specifics of the data they are routing. My employer, for example, blocks a number of Internet video protocols which originate from outside of their network. This is a fairly reasonable reaction in most cases, given the number of diversions available on the Internet which can interfere with work, but if I were trying to monitor an external video of a project site it would certainly cause me problems. Hide that feed within an IPSEC tunnel and suddenly the problem is solved.
Granted, hiding traffic this way prevents the network from helping me as well. Theoretically a traffic feed could specify QoS settings which would allow intermediate routers to prioritize real-time traffic, but the examples I have given so far are networks which are at best ambivalent to the traffic, if not outrightly hostile to it. We certainly could not expect high-priority routing in these cases.
If we accept a need for tunneling data within any application the question then comes up as to which type of tunnel should we construct. The Microsoft product uses a relatively high-level HTTPS tunnel, which encrypts and encapsulates via a specific TCP port number. This has the advantage of simplicity, since you don't have to hack deeper into the protocol stack to use it. The disadvantage is that all of the traffic has to be forced through a single TCP port. It would certainly be possible to use the same technique through a number of TCP or UDP ports, but that starts running into scaling problems, especially if you are routing arbitrary instead of application-specific traffic.
Another alternative would be to use VPN, which tunnels all traffic. This type of tunnel is much more flexible, since it lives deeper in the TCP/IP stack. When traffic emerges from the end of a VPN tunnel it can then multiplex into different addresses within a network, as well as different ports within thise devices. Variations on this theme would be IPSEC tunnels or even IPv6 encapsulation technologies like Teredo. The typical good news / bad news scenario holds here, since there are a number of protocols to choose from. It's good to have choices, but confusing to have too many of them.
One way or the other, these tunneling technologies are a key tool for next-generation peer-to-peer applications, especially if they are built on IPv6 protocols. Sometimes you just can't depend on the kindness of strangers, especially if they may be ISPs with interests counter to your own.
Larry Mittag
I have tried to do this in the past. I set up a full SharePoint server at one point and tried to gain access to it remotely. This ran afoul of my ISP's (Cox, as you can tell from my email address) regulated environment, which blocks traffic on TCP port 80 which originates from user systems. This makes sense, given that many users would otherwise set up (or have set up for them, courtesy of malware) public web servers. My goal was simply to set up a more private site for myself, family members, and a few customers.
Granted, I could do this via any number of service providers. This is the way any number of normal people do things like that, but I have rarely been accused of being normal. I have experimented a bit with the user websites that Cox allows as well, but I don't like having relatively arbitrary limits on website sizes or traffic. You can mark these up to me being a control freak or simply being too cheap to pay for the extra service, but one way or another I would just prefer to run this site on my own hardware.
The Microsoft Home Server product allowed me to do that very easily. The default website allows password-protected access to files, as well as remote control access to my home systems. The Cox blocks are bypassed via tunneling technology which effectively shields them from discovering what kind of traffic I am sending across their network. Theoretically I could set up my own porn website, although the sheer volume of traffic would probably tip them off in that case.
So what does all this have to do with embedded systems, you might well ask. The answer involves the design of peer-to-peer network devices and how these devcies can traverse arbitrary portions of the Internet without being blocked by arbitrary rules of the road in any particular segment. This is becoming a concern as routers have begun being more selective as to the specifics of the data they are routing. My employer, for example, blocks a number of Internet video protocols which originate from outside of their network. This is a fairly reasonable reaction in most cases, given the number of diversions available on the Internet which can interfere with work, but if I were trying to monitor an external video of a project site it would certainly cause me problems. Hide that feed within an IPSEC tunnel and suddenly the problem is solved.
Granted, hiding traffic this way prevents the network from helping me as well. Theoretically a traffic feed could specify QoS settings which would allow intermediate routers to prioritize real-time traffic, but the examples I have given so far are networks which are at best ambivalent to the traffic, if not outrightly hostile to it. We certainly could not expect high-priority routing in these cases.
If we accept a need for tunneling data within any application the question then comes up as to which type of tunnel should we construct. The Microsoft product uses a relatively high-level HTTPS tunnel, which encrypts and encapsulates via a specific TCP port number. This has the advantage of simplicity, since you don't have to hack deeper into the protocol stack to use it. The disadvantage is that all of the traffic has to be forced through a single TCP port. It would certainly be possible to use the same technique through a number of TCP or UDP ports, but that starts running into scaling problems, especially if you are routing arbitrary instead of application-specific traffic.
Another alternative would be to use VPN, which tunnels all traffic. This type of tunnel is much more flexible, since it lives deeper in the TCP/IP stack. When traffic emerges from the end of a VPN tunnel it can then multiplex into different addresses within a network, as well as different ports within thise devices. Variations on this theme would be IPSEC tunnels or even IPv6 encapsulation technologies like Teredo. The typical good news / bad news scenario holds here, since there are a number of protocols to choose from. It's good to have choices, but confusing to have too many of them.
One way or the other, these tunneling technologies are a key tool for next-generation peer-to-peer applications, especially if they are built on IPv6 protocols. Sometimes you just can't depend on the kindness of strangers, especially if they may be ISPs with interests counter to your own.
Larry Mittag
Labels: IPv6, TCP/IP, tunneling
Saturday, June 23, 2007
A Different Kind of Networking
It has been a while since I posted here, so I am going to diverge a bit from the topics I originally laid out. My day-to-day work and interests involve a number of network architectures, but most of them involve "live" end-to-end network connections. This is typically considered the Way That Networking Is Done, which is why it is sometimes worthwhile to take a second look at the assumptions behind it.
Much of the effort behind maintaining a network which contains radio-based mobile nodes is updating the routing information. It is relatively common in the first-generation networks of this type to have to balance between swamping the network with routing table updates or living with the spectre of stale routes. Neither of these alternatives is very palatable.
But what if your network doesn't need directly-addressed information? There are some very interesting things which can be done with a broadcast data model, one where there is a central source of data which needs to be disseminated to a series of mobile nodes. The typical architecture of such a solution in the past has been to divide the network into a small number of broadcasters and a relatively large number of receivers. In this division, the communication is typically open-loop, so each broadcast packet cannot depend on the receiver having gotten previous messages to establish a context. Each update must therefore be complete rather than incremental.
But what if we modify that architecture a bit such that each receiver in turn rebroadcasts the data? Now the central broadcaster does not need to be directly visible to each receiver in the network and there is the very real possibility of getting multiple chances to receive any single update. There are a few obvious problems such as the fact that the network would become choked very quickly if these rebraodcasts were done blindly, but it would seem that a protocol could be built to do these updates effectively.
As with most of the ideas I come up with, there is already someone else who came up with the idea and is much further along in developing it. This is also the case in this type of network, where some researchers from USC have published interesting papers on networks based on this type of architecture. There are specific references for performance analysis here and here which discuss the math behind a dissemination model and some very good ideas as to how to control and analyze such a network.
Obviouslt this is not the kind of network one would set up for general-purpose TCP/IP communications. This is more applicable to specialized embedded applications where the data dissemination model could be made to work this way. For example, traffic information updates to cars would work quite nicely in this way. One car receives an update and as it drives down the road it passes along the information to other cars as it moves in and out of range of them. It is sort of the way CB radios worked back in the "Rubber Ducky" days. Yeah, I know, I am showing my age again...
Larry Mittag
Much of the effort behind maintaining a network which contains radio-based mobile nodes is updating the routing information. It is relatively common in the first-generation networks of this type to have to balance between swamping the network with routing table updates or living with the spectre of stale routes. Neither of these alternatives is very palatable.
But what if your network doesn't need directly-addressed information? There are some very interesting things which can be done with a broadcast data model, one where there is a central source of data which needs to be disseminated to a series of mobile nodes. The typical architecture of such a solution in the past has been to divide the network into a small number of broadcasters and a relatively large number of receivers. In this division, the communication is typically open-loop, so each broadcast packet cannot depend on the receiver having gotten previous messages to establish a context. Each update must therefore be complete rather than incremental.
But what if we modify that architecture a bit such that each receiver in turn rebroadcasts the data? Now the central broadcaster does not need to be directly visible to each receiver in the network and there is the very real possibility of getting multiple chances to receive any single update. There are a few obvious problems such as the fact that the network would become choked very quickly if these rebraodcasts were done blindly, but it would seem that a protocol could be built to do these updates effectively.
As with most of the ideas I come up with, there is already someone else who came up with the idea and is much further along in developing it. This is also the case in this type of network, where some researchers from USC have published interesting papers on networks based on this type of architecture. There are specific references for performance analysis here and here which discuss the math behind a dissemination model and some very good ideas as to how to control and analyze such a network.
Obviouslt this is not the kind of network one would set up for general-purpose TCP/IP communications. This is more applicable to specialized embedded applications where the data dissemination model could be made to work this way. For example, traffic information updates to cars would work quite nicely in this way. One car receives an update and as it drives down the road it passes along the information to other cars as it moves in and out of range of them. It is sort of the way CB radios worked back in the "Rubber Ducky" days. Yeah, I know, I am showing my age again...
Larry Mittag
Monday, October 30, 2006
The Implications of Mobility
One of the key changes in assumptions around networking these days is that nodes can no longer be assumed to be at a fixed location. Most people take it for granted that their cell phones will be able to handle mobility, and that will also set their expectations for other devices attached to wireless networks. This means that embedded network designers must understand the nature of mobility and what it does to their network architecture.
The first dimension of mobility involves the ability to automatically configure a node into an arbitrary network. This sounds relatively simple, and in fact it can be so these days. Those of us with a bit of gray hair remember how hard it used to be to join an arbitrary network before DHCP became a standardized assumption. Now that this is accepted and widely supported, some people assume it solves the problem of mobility. Unfortunately, this is just the first ante for true mobility, and in fact DHCP as it stands under IPv4 does not really address the issues for mobility.
Modern mobility involves at least the capability defined by a cell phone. This means that devices must be able to transition between networks transparently to the applications they are running at the time, which means that they cannot depend on a bootup cycle to configure themselves into a new network. In fact, they most likely will be required to perform a soft handoff into that new network - meaning that they should be setting up the new connection before the old one completely goes away. This really screws up the assumptions built into DHCP under IPv4, since it is predicated on getting THE network address rather than A network address. If you can only have one network address at a time, how can you possibly be on two networks simultaneously?
Granted, it is possible to work underneath the covers to accomplish this. For example, if you define all of the wireless access points to be in one IP-level network then you can handle the transitions at the MAC layer. This gives much more control, since the routing then becomes strictly a local problem ratther than a global IP-level one. This is good as long as the entire span of the network isn't too large, but it quickly becomes problematic aas the network grows. It also makes it practically impossible to access arbitrary networks such as local 802.11 or WIMAX links, since those are sure to be under their own IP networks.
What is the solution to this? The short answer is Mobile IP, especially as it is implemented under IPv6. I will examine that solution in the next segment under this series.
Larry M.
The first dimension of mobility involves the ability to automatically configure a node into an arbitrary network. This sounds relatively simple, and in fact it can be so these days. Those of us with a bit of gray hair remember how hard it used to be to join an arbitrary network before DHCP became a standardized assumption. Now that this is accepted and widely supported, some people assume it solves the problem of mobility. Unfortunately, this is just the first ante for true mobility, and in fact DHCP as it stands under IPv4 does not really address the issues for mobility.
Modern mobility involves at least the capability defined by a cell phone. This means that devices must be able to transition between networks transparently to the applications they are running at the time, which means that they cannot depend on a bootup cycle to configure themselves into a new network. In fact, they most likely will be required to perform a soft handoff into that new network - meaning that they should be setting up the new connection before the old one completely goes away. This really screws up the assumptions built into DHCP under IPv4, since it is predicated on getting THE network address rather than A network address. If you can only have one network address at a time, how can you possibly be on two networks simultaneously?
Granted, it is possible to work underneath the covers to accomplish this. For example, if you define all of the wireless access points to be in one IP-level network then you can handle the transitions at the MAC layer. This gives much more control, since the routing then becomes strictly a local problem ratther than a global IP-level one. This is good as long as the entire span of the network isn't too large, but it quickly becomes problematic aas the network grows. It also makes it practically impossible to access arbitrary networks such as local 802.11 or WIMAX links, since those are sure to be under their own IP networks.
What is the solution to this? The short answer is Mobile IP, especially as it is implemented under IPv6. I will examine that solution in the next segment under this series.
Larry M.
Saturday, September 30, 2006
Coming Attractions
Things are starting to get interesting again in the networking world. The 802.11n standard is considered by many to be the bleeding edge as far as network architectures are concerned, but they are missing the real story. Yes, it would be nice to be able to squirt data faster than has been done in the past, and there are a few juicy acronyms like MIMO that can be tossed out to impress girls at parties (geeks are still cool, aren't they? I have trouble keeping track...). What the popular press seems to be missing is that there are fundamental changes which are just now starting to be released into the wild. A couple of these changes in particular include:
Ultra Wideband (UWB) - People seem to be waiting for UWB networks, but what they don't understand is that the technology is more fundamental than that. The 802.16 committee's efforts around UWB appear to be in chaos, but this transmission technique is showing up in practically every wireless communications corner. This is actually going to start rolling out underneath standards like Bluetooth and 1394 very soon now.
IPv6 - This rewrite of the venerable IPv4 standard will start getting some serious attention over the next few months. Most of the few interesting (to me, at least) changes about Microsoft's Vista revolve around the new networking stack and the revised versions of the applications that use it. This standard is about more than bigger addresses, and a lot of what it can do around mobility support and tunneling can be of huge benefit to networked embedded devices.
Mobile Ad-hoc Networking (MANETs) - This has all the makings of a technology feeding frenzy. I think half of the Computer Engineering PhD research papers that got published over the last couple of years have involved MANET architectures. This field is closely related to mesh networking, which is starting to see some serious product releases and is also a very hot field.
I will be talking about these subjects in more depth over the next few months. The key point I wanted to make here was that the field of networking is advancing quickly, and ma ny of those advancements can be of great use to embedded systems.
Thanks,
Larry M.
Ultra Wideband (UWB) - People seem to be waiting for UWB networks, but what they don't understand is that the technology is more fundamental than that. The 802.16 committee's efforts around UWB appear to be in chaos, but this transmission technique is showing up in practically every wireless communications corner. This is actually going to start rolling out underneath standards like Bluetooth and 1394 very soon now.
IPv6 - This rewrite of the venerable IPv4 standard will start getting some serious attention over the next few months. Most of the few interesting (to me, at least) changes about Microsoft's Vista revolve around the new networking stack and the revised versions of the applications that use it. This standard is about more than bigger addresses, and a lot of what it can do around mobility support and tunneling can be of huge benefit to networked embedded devices.
Mobile Ad-hoc Networking (MANETs) - This has all the makings of a technology feeding frenzy. I think half of the Computer Engineering PhD research papers that got published over the last couple of years have involved MANET architectures. This field is closely related to mesh networking, which is starting to see some serious product releases and is also a very hot field.
I will be talking about these subjects in more depth over the next few months. The key point I wanted to make here was that the field of networking is advancing quickly, and ma ny of those advancements can be of great use to embedded systems.
Thanks,
Larry M.
Friday, September 22, 2006
Introductions
I wanted to take this opportunity to introduce myself and give a little hint about at least my initial plans for this blog and discussion area. The topic is, of course, embedded systems communications. My primary interest is in networking, but I am not hung up on any particular type of network. I have worked on everything from RS-422 multidrop serial networks to full-blown internetworks. I once even designed a system based around a SCSI network - long before iSCSI ever came around. This is the type of creativity that embedded folks can exercise when necessary, but there are also many times (especially these days) when it is a smarter move to adhere to standards rather than submit to NIH syndrome.
This is a typical good news / bad news scenario. Embedded systems designers have the freedom to change just about anything, but that freedom must be exercised with discretion. What I would like to do is to start some discussions around the right way to design and implement these networks, as well as intelligent design choices regarding the appropriate technologies to use.
Regards,
Larry Mittag
This is a typical good news / bad news scenario. Embedded systems designers have the freedom to change just about anything, but that freedom must be exercised with discretion. What I would like to do is to start some discussions around the right way to design and implement these networks, as well as intelligent design choices regarding the appropriate technologies to use.
Regards,
Larry Mittag
