Minutes of the 2012-04-18 IAB Teleconference (Techchat)

1. Roll-call, agenda-bash, administrivia, minutes

1.1. Attendance

PRESENT

• Bernard Aboba (IAB Chair)
• Jari Arkko
• Mary Barnes (IAB Executive Director)
• Ross Callon
• Alissa Cooper
• Spencer Dawkins
• Lars Eggert (IRTF Chair)
• Mat Ford (ISOC Liaison)
• Joel Halpern
• Russ Housley (IETF Chair)
• Danny McPherson
• Cindy Morgan (IAB Executive Assistant)
• Jon Peterson
• Dave Thaler

APOLOGIES

• Marc Blanchet
• David Kessens
• Robert Sparks (IESG Liaison)
• Hannes Tschofenig

1.2. Agenda

An agenda item on the IEEE 802 Leadership Meeting was added under Other Business (3).

1.3. Administrivia

Cindy reminded the board to fill out the Doodle poll on dates for the IETF 84 BOF Coordination Call with the IESG.

Several items from the internal action item list were reviewed.

1.4. Meeting Minutes

The minutes of the 25 March 2012, 27 March 2012, 29 March 2012 and 11 April 2012 business meetings remain under review. The minutes of the IETF 83 Technical Plenary are also under review.

2. Tech Chat: Network Cost and Power Impact on Hosts and Applications

Dave Thaler delivered a presentation on “Network Cost and Power Impact on Hosts and Applications.”

The current trend is that people and devices are becoming more connected, which means that more applications are using the network. As this progresses, people are expected to be always reachable, and as such want their Internet-connected devices to be always up-to-date with email and other notifications. Because these devices need to be always reachable and up-to-date, the device must always be connected. This puts load on the network. Some effects of this additional load on the network include:

• IPv4 address exhaustion
• Port exhaustion
• Need for IPv6
• Need for Carrier-Grade Network Address Translation (CGN)
• Battery drain
• Bill shock from use of costly bandwidth

The problems of battery drain and bill shock are more visible now, and they affect applications, hosts, end-users and businesses.

2.1. Power Impact

The power impact leads to adverse effects such as user dissatisfaction with poor battery life on their devices, and the cost of electricity used to power the devices. Discovering what causes the power issues can be difficult, as it may be something inherent to the device, poor battery life, or applications that use up more power than expected.

Many of the things that consume power are not networking related. The power used for communicating data and maintaining open notification channels is networking related. Some periodic activity must be maintained even if no data is sent, in order to keep the notification channels open without timing out.

The industry wants to lower the power needs. Work is currently being done in the IEEE to tune the power usage of a link, with things like Energy-Efficient Ethernet and Fast Dormancy. Other potential solutions include tuning the intended data size, with things like compression and using lower graphics resolutions when appropriate.

Less work is being done to reduce the overhead for maintaining notification channels. The current “soft state” paradigm means that middleboxes will discard state unless they are periodically refreshed. This means that applications and devices must periodically wake up (if sleeping) and refresh state in all middleboxes for all notification channels.

Nokia did a study of home gateways that was presented at IETF 78. Their findings are outlined in the middle two rows of Figure 1 below:

Figure 1: How long is the period?

+---------------------+---------------+---------------+--------------+
|                     | UDP           | TCP           | HTTP         |
|---------------------+---------------+---------------+--------------|
|IETF recommended     | 5 minutes     | 124 minutes   | ???          |
|idle timeout         | (RFC 4787)    | (RFC 5382)    |              |
|---------------------+---------------+---------------+--------------|
|Nokia-observed       | 3 minutes     | 60 minutes    | ???          |
|median (IETF 78)     |               |               |              |
|---------------------+---------------+---------------+--------------|
|Observed minimum     | 0.5 minutes   | 4 minutes     | < 2 minutes  |
|---------------------+---------------+---------------+--------------|
|IETF recommended     | 0.5 minutes   | 120 minutes   | 0.5 minutes  |
|keep-alive interval  | (RFC 4380)    | (RFC 1122)    | (RFC 6202)   |
+---------------------+---------------+---------------+--------------+

It is difficult to determine the optimum keep-alive interval. In order to prevent missed notifications, this is often hard-coded at the minimum, which hurts battery life. To encourage longer keep-alive intervals, the market needs to adopt the work the IETF BEHAVE Working Group did for TCP and UDP, and the IETF HTTPBIS or HYBI Working Groups should do similar work for HTTP. The IETF PCP Working Group is working on a protocol that would let TCP/UDP notification channels learn the actual keep-alive intervals, but the market would still need to adopt this.

HTTP experts claim that proxies and servers must be able to throw out state at any time (i.e., have a minimum idle timeout of essentially 0). Today, many things go over HTTP that are not stateless, such as SSL VPNs and notification channels. To traverse proxies, many things try to look like HTTP, and the short timeouts result in keepalives that consume excessive amounts of power and bandwidth. As a result, everyone loses.

HTTP allows a client to upgrade to another protocol (e.g., TLS, websockets), but this may not be recognized by some middleboxes, and there is some question as to what idle timeout requirements still apply after an upgrade. The HYBI Working Group has a work item with a proposal to negotiate the timeout for things that are not classic HTTP.

2.2. Network Cost

In addition to the power issues, there are also network costs. Many ISPs have data plans with set limits on the amount of data that can be used in a month. Once those limits are reached, either no more data can be used, or more typically the price increases (sometimes dramatically). Consumers experience “bill shock” when they are charged more than expected for their data usage.

In many places, ISPs are now required to notify users when they are approaching their usage limits. This cuts down on the bill shock, but consumers may still be unhappy. In some cases, the usage may have been from something like an application downloading a patch that consumed 75% of their usage limit during the first week of the billing month, but the patch was something that was downloaded automatically and not specifically opted into by the user.

One idea is that applications could change their behaviors depending on what sort of network they are connected to. Some examples incude:

• On a “free” network: “normal behavior”
  • Stream HD video
  • download hi-resolution pictures
  • retrieve mail attachments
• On a network with data plan: use less data, and allow the user to opt-in to “normal behavior”
  • Stream lower quality video
  • download low-resolution pictures
  • only retrieve mail headers
• On an expensive network (e.g., roaming, when over the data limit on a plan)
  • allow user to opt-in
  • no video, no pictures, no mail

2.3. Conclusions

The industry has made progress in making application development easier, but issues of power and cost now impact application development. The industry needs to find solutions for these issues.

The board discussed a potential IAB document on this topic to help get a better understanding of the problem and give guidance about keep-alives. It was noted that such a document would need to be scoped carefully.

3. Other Business

Bernard announced that the meeting with the IEEE 802 leadership has been scheduled for 25 July 2012 at Cisco in Milpitas, CA. A wiki page has been set up for this meeting, and interested board members were asked to fill in their availability. Ross Callon will work with Dan Romascanu on the agenda.