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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
--
Richard Bennett
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf