Extreme congestion (was Re: inter-domain link recovery)

Tue Aug 21 17:24:49 UTC 2007

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 <swmike at swm.pp.se> 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 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 clients made use of this to better choose
> which
> > connections to prefer and which ones to avoid.  I'm unfortunately unsure
> if
> > windows has anything similar.
>
> Well, by design bittorrent will try to get everything as fast as possible
> from all peers, so any TCP session giving good performance (often low
> packet loss and low latency) will thus end up transmitting a lot of the
> data in the torrent, so by design bittorrent is kind of localised, at
> least in the sense that it will utilize fast peers more than slower ones
> and these are normally closer to you.
>
> > One problem with having clients only getting told about clients that are
> near
> > to them is that the network starts forming "cliques".  Each clique works
> as a
> > separate network and you can end up with silly things like one clique
> being
> > full of seeders, and another clique not even having any seeders at all.
> > Obviously this means that a tracker has to send a handful of addresses
> of
> > clients outside the "clique" network that the current client belongs to.
>
> The idea we pitched was that of the 50 addresses that the tracker returns
> to the client, 25 (if possible) should be from the same ASN as the client
> itself, or a nearby ASN (by some definition). If there are a lot of peers
> (more than 50) the tracker will return a random set of clients, we wanted
> this to be not random but 25 of them should be by network proximity (by
> some definition).
>
> > You want to make hosts talk to people that are close to you, you want to
> make
> > sure that hosts don't form cliques, and you want something that a
> tracker can
> > very quickly figure out from information that is easily available to
> people
> > who run trackers.  My thought here was to sort all the IP addresses, and
> send
> > the next 'n' IP addresses after the client IP as well as some random
> ones.
> > If we assume that IP's are generally allocated in contiguous groups then
> this
> > means that clients should be generally at least told about people
> nearby, and
> > hopefully that these hosts aren't too far apart (at least likely to be
> within
> > a LIR or RIR).  This should be able to be done in O(log n) which should
> be
> > fairly efficient.
>
> Yeah, we discussed that the list of IPs should be sorted (doing insertion
> sort) in the data structures in the tracker already, so what you're saying
> is one way of defining proximity that as you're saying, would probably be
> quite efficient.
>
> --
> Mikael Abrahamsson    email: swmike at swm.pp.se
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20070821/5620be5d/attachment.html>