Arbor Networks: Security to the Core

At the Internet Engineering Task Force (IETF) meeting in Dublin, Ireland last week follow-on work from the P2P Infrastructure Workshop held in late May @MIT continued.  Specifically, two birds of a feather (BoF) sessions were held, with the aim of each focusing on different areas of the P2P problem spaces.  The primary areas under study include localization and caching, congestion avoidance and quality of service (QoS).  

The first of the two BOFs, Application Layer Traffic Optimization (ALTO), discussed development of a standard for an oracle-type capability.  The basic need for the oracle function is that peers don’t know the network topology, that traffic optimization largely consists of selecting “the best” peers, and that end systems are in the worst possible place to do this.  For example, a peer in Boston is as likely to download a chunk from a peer in Tokyo as they are to download it from a local peer in Boston.  No optimization of this yields more network resource utilization - potentially congestion inducing, and less than optimal transaction performance.

What work the IETF would do here is still up for discussion, but focus on defining a standards-based interface for peer selection optimization service capabilities, perhaps to include a discovery mechanism for locating the oracle, and certainly, the Query/Response protocol for querying the oracle, seems to be the primary area of interest.  Some concerns about the scope of the ALTO work currently being far to broad are well placed.  For example, what layers constitute “network topology information” (e.g., additional examples were given about avoidance of peers on the same DOCSIS link, or the same cell tower) and what other metrics might one want to consider with such a capability - be wary that each new metric introduces exponential complexity. 

Then there’s the obvious considerations of privacy, where in order for this to be useful network operators would need to share potentially sensitive information about network topology, interconnection agreements, capacity, and infrastructure, something that’s been discussed with great reluctance many times in the past, most directly regarding the global Internet routing system and Internet Routing Registry (IRR) route policy specification, and perhaps such wariness is one of the many ingredients attributable to the insecurity of today’s routing system.  

Gaming the system also becomes an issue, as your ISPs, or their peer networks, would now potentially influence which peers you’re communicating with, and ISPs obviously have various reasons to prefer a subset of their peers over others.  Another issue with ALTO has to do with incentives.  That is, what would need to happen to incentivize both the network operator (who’s presumably flipping the bill for the capital required to make this work) AND the users or Applications that use the system?  Some economic incentives will needs to become obvious before investment and deployment occurs widely.  And, of course, there’s the issue of illegal content and what implications this would have on oracle or cache operators.

The ALTO work is certainly not a panacea, but I’m convinced there is some room for optimization here, and work the IETF can do to help.

The other of the two BOFs, Techniques for Advanced Networking Applications (TANA), I believe to be much more focused.  The group is addressing issues with Transport layer protocols, and specifically, TCP in the absence of Explicit Congestion Notification (ECN), where Transport layer protocols are used to transmit large amounts of data for some reasonable amount of time (not extremely short-lived transactions), where the buffer at the head of the bottleneck link (e.g., the cable modem) fills and results in poor performance across all transactions for all applications using the network.  

The TANA problem space has become most obvious and acute to date when P2P or similar applications upload data over constrained access uplinks, e.g., cable access networks, but can occur in other places as well.  In the example of a cable access loop, the problem manifests itself in a manner similar to this:

• a host establishes one or more transport connections with a peer and begins transmitting upstream via TCP
• there’s no feedback from the network or remote end yet (e.g., via ECN) and so the host continues transmitting
• the local cable modem (CM) requests HFC upstream transmit capacity, capacity that’s limited and shared across all the CMs connected to a given CMTS DOCSIS Domain, and buffers packets received from the host until transmit slots (bytes, not packets) for data chunks are allocated
• TCP has not been designed to minimize the extra delay introduced by the network itself, and as a side-effect of filling the buffer until it experiences drop-tail loss, maximizes the delay
• the result is that other applications using the network, such as VoIP traffic, have their packets backed up behind the buffered TCP traffic, with as much as 4 seconds of delay, and are virtually unusable
• This problem becomes more obvious with applications that open multiple parallel TCP connections in order to optimize transactions rates (e.g., P2P, iTunes, Google Maps, etc..).

The TANA work is focusing on broadly applicable techniques that allow large amounts of data to be consistently transmitted without substantially affecting the delays of other users or applications, something that seems well within the IETF scope.  There appears to be genuine interest from multiple stakeholders in the community (e.g., Comcast, Pando, BitTorrent, etc.)  for both TANA and ALTO related work, let’s hope this collaboration continues.  I suspect and hope both these work areas continue in the IETF, finding a home in IETF working groups under the Transport or Real-Time Applications & Infrastructure (RAI) areas, specifically.

The presentations from the ALTO and TANA BOFs are available here.  The mailing list where discussions are occurring is p2pi@ietf.org, with archives and other information available here.  

Ohh, and if you’re wondering, the Guinness is indeed much better there! 

This entry was posted on Wednesday, August 6th, 2008 at 5:07 pm and is filed under Arbor Networks. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.