Subject: Time Shifting of Internet Traffic

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 13 Sep 2010 21:46:16 -0400

I am not finding the net neutrality debate according to K-Street to be very
useful or stimulating.

At the end of the day we have a limited amount of bandwidth available and we
can help matters if people co-operate where it is in their interests.
Whether or not we choose to do so does not in any way justify using the fact
that I have limited choices in bandwidth provider to ensure that my options
for content and/or VOIP telephone service are similarly limited.

One area that might be fruitful for cooperation is in bulk time shifting of
traffic. I am not so much talking about packet level prioritization here. I
am thinking more of when I choose to back up my systems over the net.

The way I look at it, the net is a bit like the power grid in that there is
an opportunity to reduce capacity requirements by shifting tasks from peak
to off-peak. In particular I have several RAID arrays that I would like to
back up with a total of something like 2Tb of data.

At present there is no incentive for me to play nice other than the risk
that my activities will clog my local net. In fact it is arguably in my
interest to do at least some of my backups at peak time when I am not using
the net since that encourages my ISP to upgrade their circuits. I don't
actually do that but others might.

It would be nice if there was some way that really high bandwidth apps that
can tolerate long latency could negotiate a good time to do this sort of
thing so as to minimize inconvenience.

-- 
Website: http://hallambaker.com/

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 14 Sep 2010 16:54:47 +0100

On 14 Sep 2010, at 02:46, Phillip Hallam-Baker wrote:

> I am not finding the net neutrality debate according to K-Street to be very useful or stimulating.
> 
> At the end of the day we have a limited amount of bandwidth available and we can help matters if people co-operate where it is in their interests. Whether or not we choose to do so does not in any way justify using the fact that I have limited choices in bandwidth provider to ensure that my options for content and/or VOIP telephone service are similarly limited.
> 
> 
> One area that might be fruitful for cooperation is in bulk time shifting of traffic. I am not so much talking about packet level prioritization here. I am thinking more of when I choose to back up my systems over the net.
> 
> The way I look at it, the net is a bit like the power grid in that there is an opportunity to reduce capacity requirements by shifting tasks from peak to off-peak. In particular I have several RAID arrays that I would like to back up with a total of something like 2Tb of data. 
> 

I know of ISPs in the UK that have seen success by building their Broadband packages around an incentive to do exactly that.

Two models I have seen are:
1) Package X has a transfer cap of Y GB/month but only transfers between 08:00 and 24:00 count towards the cap.

2) Package X has traffic shaping applied where different protocols are shaped to different maximum throughputs (per customer) depending on protocol & time of day. One then selects the package that provides the application performance one wants for the applications one uses. See http://www.plus.net/support/broadband/speed_guide/download_speeds.shtml for an example.

Ben

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Sep 2010 09:48:12 +1200

> I am not finding the net neutrality debate according to K-Street to be very

+1. No, +100.

> am thinking more of when I choose to back up my systems over the net.

RFC 3662 is aimed at this sort of application. Whether it has been
usefully deployed, I cannot say.

    Brian

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

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 14 Sep 2010 23:25:55 -0400

Isn't this also basically the point of LEDBAT and CONEX?  For  
applications to sense congestion and back off aggressively -- i.e., to  
time-shift themselves into the future?

---

From: Richard Bennett <[email-masked]>
Date: Tue, 14 Sep 2010 20:34:00 -0700

There's future and then there's future. LEDBAT wants to sense 
congestion and back off to allow other apps with more pressing needs to 
use particular pipes, not so much to defer as to find less congested 
paths. The LEDBAT assumption is that there are many paths to the 
content, and in fact many copies of the content, so it's best for 
everyone to find the least congested paths. So it's mainly time-shifting 
on a subsecond scale. CONEX deals with a different problem, one in which 
there is typically one path that the end points to take (one asymmetric 
path, in most cases) and applications therefore needs to get feedback 
about the congestion they're causing and to give information about how 
the judge the importance of overcoming the congestion when choosing to 
overcome it may have economic consequences.

I think it's correct to view both of these systems as more sophisticated 
alternatives to large scale time shifting and monthly volume caps. Daily 
and monthly caps simply don't operate on the correct time scale for 
Internet congestion mediation.

RB

-- 
Richard Bennett