Subject: [alto] On dominant characteristics of residential broadband Internet traffic

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 10 Feb 2010 15:14:57 -0600

Hi: During the Hiroshima IETF, there was some discussion on
how to use the provisioned bandwidth for ALTO [1].

I suspect that one reason why there hasn't been a more
in-depth list discussion on this topic after Hiroshima may be
the lack of public availability of specific characteristics
of residential networks.  Some aspects we touched upon in
the Hiroshima discussion included the frequency by which
the IP address changes to make it long-term reliable host
identifier, etc.

At about the same time we were meeting in Hiroshima, the
ACM IMC conference was taking place in Chicago.  One of the
papers there is entitled "On dominant characteristics of
residential broadband Internet traffic" by Maier et al. [2].
The data is based on 20,000 residential DSL lines belonging to
a major European ISP (we probably should stay away from
drawing a general conclusion for other access methods like
cable and fiber.)  Regardless, the paper makes for some
interesting reading and provides some insight into DSL
residential broadband.

The findings in here are interesting and we can use some
of these for our work in ALTO.  To summarize some of the
work:

1) Less than a quarter of active lines exceed 50% of their
  bandwidth for even one second over a 5m period.  During the
  day, 50-60% of the active lines achieve at least a 10% band-
  width utilization.

2) Session durations are surprisingly short -- a median
  duration of only 20-30m.

3) IP addresses are re-assigned frequently, with up to 4%
  of addresses assigned more than 10 times a day, and 50%
  are reassigned at least twice in 24h (in other words,
  the use of IP addresses as host identifiers can be
  misleading over fairly short time scales.)

4) HTTP dominates (> 50% of traffic) in terms of bytes due
  to streaming of Youtube videos, etc.

5) Examining TCP round-trip times, for many TCP connections the
  access bandwidth-delay product exceeded the advertised windows,
  making it impossible for the connection to saturate the
  access link.

[1] Item 3 in http://trac.tools.ietf.org/wg/alto/trac/wiki/Ietf76
[2] G. Maier, A. Feldmann, V. Paxon, and M. Allman, "On dominant
  characteristics of residential broadband Internet traffic,"
  Proceedings of the 9th ACM SIGCOMM conference on Internet
  measurement conference (IMC), pp. 90-102, November 2009.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web:   http://ect.bell-labs.com/who/vkg/

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 10 Feb 2010 16:44:06 -0500

Hello Vijay,

You said " we probably should stay away from drawing a general conclusion
for other access methods like cable and fiber".

But I would say we cannot draw a general conclusion at all. I would say this
changes across DSL provider and different regions/countries.
 
I do not think this is tied to access technology but more to ISP policy and
address assignment technology. In the US although it changes, you can go for
much longer with the same IP address in DSL networks.

In general I would say these matter.
  
1 -  Do the ISP (or division of the ISP) that provides broadband have enough
IPv4 addresses?

2 - Do they use PPPoX or DHCP or something else?

3 - Flat-rate or not. Actually, this should not actually matter

I think probably the IP addresses assignment policy/technology has not
caught up with users and a low idle (or session) timeout in their CPEs. It
is usually much easier and practical to reassign the same IP address if
possible due to billing, logging, legal interception, OAM, etc.

4 - In a IPv6-native world probably this will not matter.

Thanks,

Reinaldo

---

From: Ping Pan <[email-masked]>
Date: Wed, 10 Feb 2010 15:10:00 -0800

Interesting bandwidth usage information.

Here is a related draft on bandwidth provisioning and management from
Comcast (
http://www.ietf.org/id/draft-livingood-woundy-congestion-mgmt-01.txt): when
a user pumps traffic at 70-80% of provisioned thresholds for 15 minutes,
his/her packets will be added to a low-priority queue that may be dropped in
event of congestion.

I guess in the context of P2P, the tracker manager needs to swap seeds every
15 minutes. :-)

- Ping

On Wed, Feb 10, 2010 at 1:14 PM, Vijay K. Gurbani <[email-masked]>wrote:

> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto
>

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 10 Feb 2010 15:27:50 -0800

On Feb 10, 2010, at 3:10 PM, Ping Pan wrote:

> Here is a related draft on bandwidth provisioning and management from Comcast (http://www.ietf.org/id/draft-livingood-woundy-congestion-mgmt-01.txt): when a user pumps traffic at 70-80% of provisioned thresholds for 15 minutes, his/her packets will be added to a low-priority queue that may be dropped in event of congestion.
> 
> I guess in the context of P2P, the tracker manager needs to swap seeds every 15 minutes. :-) 

Actually, unless there is near starvation issues, it shouldn't be a problem:  If the traffic usage drops below 70% due to the lower priority view, I would expect it to bounce back up in the next epoch.  If it doesn't, well, you are still >70% of listed capacity during your low priority time.

Basically, "Square wave" the traffic doesn't help if the thershold is set at any value >50%, because either you will stay in low proirity (but still be sending >50%), or be bounced back up to high priority anyway.

Thats one of the things I like about the scheme, both as a researcher and happy comcast customer: its very hard to game, but there is very little reason TO try to game it.

---

From: Ping Pan <[email-masked]>
Date: Wed, 10 Feb 2010 15:42:57 -0800

> Thats one of the things I like about the scheme, both as a researcher and happy comcast customer: its very hard to game, but there is very little reason TO try to game it.

Yup! It's protocol/app-agnostic You are right. Thanks!

Regards,

- Ping