On Tue, 21 Aug 2007, Alexander Harrowell wrote:
This is what I eventually upshot..
http://www.telco2.net/blog/2007/08/variable_speed_limits_for_the.html
You wrote in your blog:
The problem is that if there is a major problem, very large numbers of
users applications will all try to
This is what I eventually upshot..
http://www.telco2.net/blog/2007/08/variable_speed_limits_for_the.html
On 8/19/07, Mikael Abrahamsson [EMAIL PROTECTED] wrote:
On Sun, 19 Aug 2007, Perry Lorier wrote:
Many networking stacks have a TCP_INFO ioctl that can be used to query
for
more
On Thu, Aug 16, 2007 at 10:55:59PM +0200, Mikael Abrahamsson wrote:
[snip]
We've been pitching the idea to bittorrent tracker authors to include a
BGP feed and prioritize peers that are in the same ASN as the user
himself, but they're having performance problems already so they're not so
On Sun, 19 Aug 2007, Perry Lorier wrote:
Many networking stacks have a TCP_INFO ioctl that can be used to query for
more accurate statistics on how the TCP connection is fairing (number of
retransmits, TCP's current estimate of the RTT (and jitter), etc). I've
always pondered if bittorrent
We've been pitching the idea to bittorrent tracker authors to include
a BGP feed and prioritize peers that are in the same ASN as the user
himself, but they're having performance problems already so they're
not so keen on adding complexity. If it could be solved better at the
client level
On 8/17/07, Adrian Chadd [EMAIL PROTECTED] wrote:
On Thu, Aug 16, 2007, [EMAIL PROTECTED] wrote:
I'm pushing an agenda in the open source world to add
some concept of locality, with the purpose of moving traffic off ISP
networks when I can. I think the user will be just as happy or
Ted Hardie wrote:
Fred Baker writes:
Hence, moving a file into a campus doesn't mean that the campus has the file and
will stop bothering you. I'm pushing an agenda in the open source world to add
some concept of locality, with the purpose of moving traffic off ISP
networks when I
Sam Stickland wrote:
Ted Hardie wrote:
Fred Baker writes:
Hence, moving a file into a campus doesn't mean that the campus has
the file and will stop bothering you. I'm pushing an agenda in the
open source world to add some concept of locality, with the purpose
of moving traffic off
On Fri, Aug 17, 2007 at 10:54:47AM +0100, Sam Stickland wrote:
Ted Hardie wrote:
Fred Baker writes:
Hence, moving a file into a campus doesn't mean that the campus has the
file and will stop bothering you. I'm pushing an agenda in the open
source world to add some concept of
On Thu, Aug 16, 2007 at 09:07:31AM -0700, Hex Star wrote:
How does akamai handle traffic congestion so seamlessly? Perhaps we should
look at existing setups implemented by companies such as akamai for
guidelines regarding how to resolve this kind of issue...
and if you are a Content
On Aug 17, 2007, at 6:57 AM, Stephen Wilcox wrote:
On Thu, Aug 16, 2007 at 09:07:31AM -0700, Hex Star wrote:
How does akamai handle traffic congestion so seamlessly?
Perhaps we should
look at existing setups implemented by companies such as akamai
for
guidelines regarding how to
On Wed, Aug 15, 2007, Fred Baker wrote:
And finally why only do this during extreme congestion? Why not
always
do it?
I think I would always do it, and expect it to take effect only under
extreme congestion.
Well, emprically (on multi-megabit customer-facing links) it takes
effect
On Aug 15, 2007, at 10:13 PM, Adrian Chadd wrote:
Well, emprically (on multi-megabit customer-facing links) it takes
effect immediately and results in congestion being avoided (for
values of avoided.) You don't hit a hm, this is fine and hm,
this is congested; you actually notice a much
On Wed, 15 Aug 2007, Fred Baker wrote:
On Aug 15, 2007, at 8:39 PM, Sean Donelan wrote:
On Wed, 15 Aug 2007, Fred Baker wrote:
So I would suggest that a third thing that can be done, after the other
two avenues have been exhausted, is to decide to not start new sessions
unless there is some
So that's why I keep returning to the need to pushback traffic a couple
of ASNs back. If its going to get dropped anyway, drop it sooner.
ECN
An Internet variable speed limit is a nice idea, but there are some
serious trust issues; applications have to trust the network implicitly not
to issue gratuitous slow down messages, and certainly not to use them for
evil purposes (not that I want to start a network neutrality flamewar...but
what
On Wed, Aug 15, 2007 at 12:58:48PM -0700, Tony Li wrote:
On Aug 15, 2007, at 9:12 AM, Stephen Wilcox wrote:
Remember the end-to-end principle. IP backbones don't fail with
extreme
congestion, IP applications fail with extreme congestion.
Hmm I'm not sure about that... a 100% full
On Thu, Aug 16, 2007 at 10:55:34AM +0100, Alexander Harrowell wrote:
An Internet variable speed limit is a nice idea, but there are some
serious trust issues; applications have to trust the network implicitly
not to issue gratuitous slow down messages, and certainly not to use them
In many cases, yes. I know of a certain network that ran with
30% loss for a matter of years because the option didn't
exist to increase the bandwidth. When it became reality,
guess what they did.
How many people have noticed that when you replace a circuit with a
higher capacity one, the
On Thu, 16 Aug 2007, Alexander Harrowell wrote:
An Internet variable speed limit is a nice idea, but there are some
serious trust issues; applications have to trust the network implicitly not
to issue gratuitous slow down messages, and certainly not to use them for
Yeah, that's why I was
How does akamai handle traffic congestion so seamlessly? Perhaps we should
look at existing setups implemented by companies such as akamai for
guidelines regarding how to resolve this kind of issue...
On Thu, 16 Aug 2007, [EMAIL PROTECTED] wrote:
How many people have noticed that when you replace a circuit with a
higher capacity one, the traffic on the new circuit is suddenly greater
than 100% of the old one. Obviously this doesn't happen all the time,
such as when you have a 40%
On Wed, 15 Aug 2007, Randy Bush wrote:
So that's why I keep returning to the need to pushback traffic a couple
of ASNs back. If its going to get dropped anyway, drop it sooner.
ECN
Oh goody, the whole RED, BLUE, WRED, AQM, etc menagerie.
Connections already in progress (i.e. the ones with
yes.
On Aug 16, 2007, at 12:29 AM, Randy Bush wrote:
So that's why I keep returning to the need to pushback traffic a
couple
of ASNs back. If its going to get dropped anyway, drop it sooner.
ECN
So that's why I keep returning to the need to pushback traffic a couple
of ASNs back. If its going to get dropped anyway, drop it sooner.
ECN
Oh goody, the whole RED, BLUE, WRED, AQM, etc menagerie.
wow! is that what ECN stands for? somehow, in all this time, i missed
that. live and
Yeah, that's why I was limiting the need (requirement) to only 1-few
ASN hops upstream. I view this as similar to some backbones offering
a special blackhole everything BGP community that usually is not
transitive. This is the Oh Crap, Don't Blackhole Everything but Slow
Stuff Down BGP
Alexander Harrowell wrote:
Yeah, that's why I was limiting the need (requirement) to only 1-few
ASN hops upstream. I view this as similar to some backbones offering
a special blackhole everything BGP community that usually is not
transitive. This is the Oh Crap, Don't Blackhole Everything
On 8/16/07, Randy Bush [EMAIL PROTECTED] wrote:
Yeah, that's why I was limiting the need (requirement) to only 1-few
ASN hops upstream. I view this as similar to some backbones offering
a special blackhole everything BGP community that usually is not
transitive. This is the Oh Crap,
On Aug 16, 2007, at 7:46 AM, [EMAIL PROTECTED] wrote:
In many cases, yes. I know of a certain network that ran with 30%
loss for a matter of years because the option didn't exist to
increase the bandwidth. When it became reality, guess what they did.
How many people have noticed that when
On Thu, 16 Aug 2007, Randy Bush wrote:
Alexander Harrowell wrote:
Yeah, that's why I was limiting the need (requirement) to only 1-few
ASN hops upstream. I view this as similar to some backbones offering
a special blackhole everything BGP community that usually is not
transitive. This is the
Mikael Abrahamsson wrote:
On Thu, 16 Aug 2007, [EMAIL PROTECTED] wrote:
How many people have noticed that when you replace a circuit with a
higher capacity one, the traffic on the new circuit is suddenly
greater than 100% of the old one. Obviously this doesn't happen all
the time, such
On Thu, 16 Aug 2007, Deepak Jain wrote:
Depends on your traffic type and I think this really depends on the
granularity of your study set (when you are calculating 80-90% usage). If you
upgrade early, or your (shallow) packet buffers convince to upgrade late, the
effects might be different.
On Thu, 16 Aug 2007, Fred Baker wrote:
world, they're perfectly happen to move it around the world. Hence, moving a
file into a campus doesn't mean that the campus has the file and will stop
bothering you. I'm pushing an agenda in the open source world to add some
concept of locality, with
Fred Baker writes:
Hence, moving a file into a campus doesn't mean that the campus has the file
and
will stop bothering you. I'm pushing an agenda in the open source world to
add
some concept of locality, with the purpose of moving traffic off ISP
networks when I can. I think the user
The TCPs don't slow down. They use the bandwidth you have
made available instead.
in your words, the traffic on the new circuit is suddenly
greater than 100% of the old one.
Exactly!
To be honest, I first encountered this when Avi Freedman upgraded one of
his upstream connections from
On Thu, Aug 16, 2007, [EMAIL PROTECTED] wrote:
I'm pushing an agenda in the open source world to add
some concept of locality, with the purpose of moving traffic off ISP
networks when I can. I think the user will be just as happy or
happier, and folks pushing large optics will
On Aug 15, 2007, at 8:35 AM, Sean Donelan wrote:
Or should IP backbones have methods to predictably control which IP
applications receive the remaining IP bandwidth? Similar to the
telephone network special information tone -- All Circuits are
Busy. Maybe we've found a new use for ICMP
On Wed, 15 Aug 2007, Fred Baker wrote:
On Aug 15, 2007, at 8:35 AM, Sean Donelan wrote:
Or should IP backbones have methods to predictably control which IP
applications receive the remaining IP bandwidth? Similar to the telephone
network special information tone -- All Circuits are Busy.
Hey Sean,
On Wed, Aug 15, 2007 at 11:35:43AM -0400, Sean Donelan wrote:
On Wed, 15 Aug 2007, Stephen Wilcox wrote:
(Check slide 4) - the simple fact was that with something like 7 of 9
cables down the redundancy is useless .. even if operators maintained
N+1 redundancy which is unlikely
let me answer at least twice.
As you say, remember the end-2-end principle. The end-2-end
principle, in my precis, says in deciding where functionality should
be placed, do so in the simplest, cheapest, and most reliable manner
when considered in the context of the entire network. That is
On Wed, 15 Aug 2007 11:59:54 EDT, Sean Donelan said:
Since major events in the real-world also result in a lot of new
traffic, how do you signal new sessions before they reach the affected
region of the network? Can you use BGP to signal the far-reaches of
the Internet that I'm having
Congestion and applications...
My opinion:
A tier 1 provider does not care what traffic it carries. That is all a
function of the application not the network.
A tier 2 provider may do traffic shaping, etc.
A tier 3 provider may decide to block traffic paterns.
--
of Chiloé Temuco
Sent: Wed 8/15/2007 6:06 PM
To: nanog@merit.edu
Subject: Re: Extreme congestion (was Re: inter-domain link recovery)
Congestion and applications...
My opinion:
A tier 1 provider does not care what traffic it carries. That is all a
function of the application not the network
On Aug 15, 2007, at 8:39 PM, Sean Donelan wrote:
Or would it be better to let the datagram protocols fight it out
with the session oriented protocols, just like normal Internet
operations
Session protocol start packets (TCP SYN/SYN-ACK, SCTP INIT, etc)
1% queue
Everything else
[...Lots of good stuff deleted to get to this point...]
On Wed, 15 Aug 2007, Fred Baker wrote:
So I would suggest that a third thing that can be done, after the other two
avenues have been exhausted, is to decide to not start new sessions unless
there is some reasonable chance that they will
45 matches
Mail list logo
