Re: Time Shifting of Internet Traffic

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

On 9/14/2010 8:25 PM, Richard L. Barnes wrote:
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?



On Sep 14, 2010, at 5:48 PM, Brian E Carpenter wrote:

On 2010-09-14 13:46, Phillip Hallam-Baker wrote:
I am not finding the net neutrality debate according to K-Street to be very
useful or stimulating.

+1. No, +100.


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.

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

   Brian


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.



------------------------------------------------------------------------

_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

--
Richard Bennett

_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]