[98862] in North American Network Operators' Group
Re: Extreme congestion (was Re: inter-domain link recovery)
daemon@ATHENA.MIT.EDU (Alexander Harrowell)
Tue Aug 21 14:40:00 2007
Date: Tue, 21 Aug 2007 18:24:49 +0100
From: "Alexander Harrowell" <a.harrowell@gmail.com>
To: "Mikael Abrahamsson" <swmike@swm.pp.se>
Cc: "Perry Lorier" <perry@coders.net>, nanog@merit.edu
In-Reply-To: <Pine.LNX.4.64.0708191706440.15618@uplift.swm.pp.se>
Errors-To: owner-nanog@merit.edu
------=_Part_94046_30557865.1187717089818
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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@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@swm.pp.se
>
------=_Part_94046_30557865.1187717089818
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
This is what I eventually upshot..<br><br><a href="http://www.telco2.net/blog/2007/08/variable_speed_limits_for_the.html">http://www.telco2.net/blog/2007/08/variable_speed_limits_for_the.html</a><br><br><div><span class="gmail_quote">
On 8/19/07, <b class="gmail_sendername">Mikael Abrahamsson</b> <<a href="mailto:swmike@swm.pp.se">swmike@swm.pp.se</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>On Sun, 19 Aug 2007, Perry Lorier wrote:<br><br>> Many networking stacks have a "TCP_INFO" ioctl that can be used to query for<br>> more accurate statistics on how the TCP connection is fairing (number of
<br>> retransmits, TCP's current estimate of the RTT (and jitter), etc). I've<br>> always pondered if bittorrent clients made use of this to better choose which<br>> connections to prefer and which ones to avoid. I'm unfortunately unsure if
<br>> windows has anything similar.<br><br>Well, by design bittorrent will try to get everything as fast as possible<br>from all peers, so any TCP session giving good performance (often low<br>packet loss and low latency) will thus end up transmitting a lot of the
<br>data in the torrent, so by design bittorrent is kind of localised, at<br>least in the sense that it will utilize fast peers more than slower ones<br>and these are normally closer to you.<br><br>> One problem with having clients only getting told about clients that are near
<br>> to them is that the network starts forming "cliques". Each clique works as a<br>> separate network and you can end up with silly things like one clique being<br>> full of seeders, and another clique not even having any seeders at all.
<br>> Obviously this means that a tracker has to send a handful of addresses of<br>> clients outside the "clique" network that the current client belongs to.<br><br>The idea we pitched was that of the 50 addresses that the tracker returns
<br>to the client, 25 (if possible) should be from the same ASN as the client<br>itself, or a nearby ASN (by some definition). If there are a lot of peers<br>(more than 50) the tracker will return a random set of clients, we wanted
<br>this to be not random but 25 of them should be by network proximity (by<br>some definition).<br><br>> You want to make hosts talk to people that are close to you, you want to make<br>> sure that hosts don't form cliques, and you want something that a tracker can
<br>> very quickly figure out from information that is easily available to people<br>> who run trackers. My thought here was to sort all the IP addresses, and send<br>> the next 'n' IP addresses after the client IP as well as some random ones.
<br>> If we assume that IP's are generally allocated in contiguous groups then this<br>> means that clients should be generally at least told about people nearby, and<br>> hopefully that these hosts aren't too far apart (at least likely to be within
<br>> a LIR or RIR). This should be able to be done in O(log n) which should be<br>> fairly efficient.<br><br>Yeah, we discussed that the list of IPs should be sorted (doing insertion<br>sort) in the data structures in the tracker already, so what you're saying
<br>is one way of defining proximity that as you're saying, would probably be<br>quite efficient.<br><br>--<br>Mikael Abrahamsson email: <a href="mailto:swmike@swm.pp.se">swmike@swm.pp.se</a><br></blockquote></div>
<br>
------=_Part_94046_30557865.1187717089818--
