[ledbat] Correcting misinformation in RFC5290

Bob Briscoe <rbriscoe@jungle.bt.co.uk> Fri, 13 November 2009 02:35 UTC

Return-Path: <rbriscoe@jungle.bt.co.uk>
X-Original-To: ledbat@core3.amsl.com
Delivered-To: ledbat@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EE373A683D for <ledbat@core3.amsl.com>; Thu, 12 Nov 2009 18:35:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Level:
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[AWL=-1.428, BAYES_05=-1.11, DNS_FROM_RFC_BOGUSMX=1.482, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8qTv8NlxKqp for <ledbat@core3.amsl.com>; Thu, 12 Nov 2009 18:35:48 -0800 (PST)
Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id C29D63A697D for <ledbat@ietf.org>; Thu, 12 Nov 2009 18:35:47 -0800 (PST)
Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 13 Nov 2009 02:36:16 +0000
Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 13 Nov 2009 02:36:15 +0000
Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1258079775118; Fri, 13 Nov 2009 02:36:15 +0000
Received: from MUT.jungle.bt.co.uk ([10.73.128.50]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id nAD2a7cE032723; Fri, 13 Nov 2009 02:36:09 GMT
Message-Id: <200911130236.nAD2a7cE032723@bagheera.jungle.bt.co.uk>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 13 Nov 2009 02:20:41 +0000
To: rpenno@juniper.net
From: Bob Briscoe <rbriscoe@jungle.bt.co.uk>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158
X-OriginalArrivalTime: 13 Nov 2009 02:36:15.0961 (UTC) FILETIME=[12B25C90:01CA640A]
Cc: "ledbat@ietf.org" <ledbat@ietf.org>
Subject: [ledbat] Correcting misinformation in RFC5290
X-BeenThere: ledbat@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mailing list of the LEDBAT WG <ledbat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ledbat>, <mailto:ledbat-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ledbat>
List-Post: <mailto:ledbat@ietf.org>
List-Help: <mailto:ledbat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ledbat>, <mailto:ledbat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Nov 2009 02:35:54 -0000

Reinaldo,

RFC5290 (individual submission via RFC Editor) repeats a fallacy widely available from Internet searches about OS limits to numbers of connections (see S.3.2.2). It describes a commercial limit to file & printer sharing connections in desktop licensed OSs but says it's a limit on all TCP connections. We should also clarify confusions with limits on half-open TCP connections.

Below is the mail I sent to the authors. But the fallacy remained in the published RFC (being an individual RFC, there was no working group to oversee its publication).

Could you add appropriate text in ledbat-app-practices-recommendations to correct the misinformation in RFC5290.

[I just said in the LEDBAT meeting that I had posted the mail below on the tsvwg list - it was actually only a private mail to the authors. But it seems to have been overlooked anyway.]



Bob

Date: Tue, 16 Oct 2007 19:08:48 +0100
To: "FLOYD, Sally" <floyd@acm.org>, "ALLMAN, Mark" <mallman@icir.org>
From: Bob Briscoe <rbriscoe@jungle.bt.co.uk>
Subject: Correction to draft-floyd-tsvwg-besteffort-01

Sally, Mark,

Off list.

In section 3.2.1, you have an inaccuracy. You say
"                                 ...
For peer-to-peer traffic, different
   operating systems have different limitations on the maximum
number of
   peer-to-peer connections; Windows XP Pro has a limit of ten
   simultaneous peer-to-peer connections, Windows XP Home (for
the
   client) has a limit of five, and an OS X client has a limit
of ten
  
[http://tools.ietf.org/html/draft-floyd-tsvwg-besteffort-01#ref-P2P" rel="nofollow">
P2P].

..."
I suggest you avoid quoting forums on this subject - it is an area in which you will get as many opinions as postings (which is why this is off-list - even tho I've been careful to check my sources, some of the info below is less solidly cited than others).
First a picky point. There are no OSs that specifically limit "p2p connections", given the OS wouldn't be able to tell whether a connection was p2p. But there's a more serious misunderstanding here...

All the limits you cite above are solely limits on the number of remote devices connecting to the built-in services of the respective OSs, like file and printer sharing and more recently, in the case of Windows, the built-in Web server called IIS. They are not limits to the number of IP sockets in listen mode.

These limits were introduced long before p2p file-sharing became popular (I recall they were around in Windows NT4.0), in order to protect sales of the server version of each OS for use as enterprise file-servers. I believe most p2p filesharing software wouldn't work if these limits applied to IP server sockets generally.

There is a limit in Windows (XP from service pack 2, and Vista) on the number of TCP connections in half open state - this limits the rate the OS can open new TCP connections, whether as a client or a server, to 10 per RTT.

Clarification: This is a limit on the number of half-open connections to *different* IP addresses.

But there's no limit on the opening rate of non-TCP connections (e.g. UDP). This was designed to slow worm propagation, but as collateral damage, it also hits a lot of p2p software that opens a hundred or so connections at once. Microsoft hard coded this limit into the TCP/IP stack, but two workrounds have been published (at least one is just a binary edit of the TCPIP.SYS file).

Murari Sridharan says that this half-open connections limit only applies to Windows XP-SP2+ & Vista.


More
----
Even the article you quote says there are no limits in Mac OS X to the number of server connections, other than for Apple's file sharing service (Apple file protocol - AFP), which is limited to 10. The latter part is confirmed by apple:
<http://docs.info.apple.com/article.html?artnum=107237" rel="nofollow"> http://docs.info.apple.com/article.html?artnum=107237>
Windows 2000, XP & Vista have very similar limits to OS X. The important text in the Microsoft article below is "The connection limit refers to the number of redirector-based connections and is enforced for any file, print, named pipe, or mail slot session. The TCP connection limit is not enforced, but it may be bound by legal agreement to not permit more than 10 clients."
<http://support.microsoft.com/default.aspx?scid=kb;en-us;314882" rel="nofollow"> http://support.microsoft.com/default.aspx?scid=kb;en-us;314882>

The XP Pro license says:
"You may permit a maximum of ten (10) computers or other electronic devices (each a “Device”) to connect to the Workstation Computer to utilize the services of the Product solely for File and Print services, Internet Information Services, and remote access (including connection sharing and telephony services)."

There is plenty of ambiguity in these terms, but I think remote access is usually used by Microsoft to mean access to a remote device through this computer (not access by a remote device to this computer). The examples in parentheses support this assumption. All the mentioned services are those Windows actually limits. While general IP connections are separate and not limited by the OS software. So I believe the licence is reinforcing what the OS actually limits, rather than widening the definition of the limits by legal means.

Win 95/98 had a limit to the TCP/IP stack of 100 concurrent connections, but that was configurable via the registry <http://support.microsoft.com/kb/158474/EN-US/" rel="nofollow"> http://support.microsoft.com/kb/158474/EN-US/>.

I don't know about Mac OS X limits to general IP server sockets (in listen mode) but I doubt there are any (if you find anyone complaining of a limit, let me know, but I can't find any via a brief scan of the results from a Web search engine).

-----
BTW, the Azureus app (popular BitTorrent s/w) typically holds more than a hundred connections open to other peers, of which about half (by symmetry) will be server sockets. Usually, only about 10% are actively transferring data at any one time, but all hundred or so are open TCP connections. E.g. This calculator is a popular way to decide how to config Bit Torrent clients:
<http://infinite-source.de/az/az-calc.html" rel="nofollow"> http://infinite-source.de/az/az-calc.html>
If you put in 256kbps upload (typical for 2M or 8Mbbps download DSL services), it advises 134 max connections.

BTW^2, Microsoft advise users how to increase the limit on HTTP downloads in a couple of places:
<http://support.microsoft.com/kb/835821/en-gb" rel="nofollow"> http://support.microsoft.com/kb/835821/en-gb> (Find "MaxConnectionsPerServer" within the page)
<http://support.microsoft.com/kb/282402" rel="nofollow"> http://support.microsoft.com/kb/282402> (Note the limp caveat at the bottom of the page)

BTW^3 (nothing to do with no's of connections), were you aware that Joost, the p2p video on demand service that is becoming increasingly popular, uses UDP not TCP for its media transfers. Currently at about a total of 700kbps inward and 220kbps outward in 1kB packets. According to the Joost data centre network architect, this is because "congestion control would kill video streaming":
<http://www.uknof.org.uk/uknof7/MacCarthaigh-Joost.pdf" rel="nofollow"> http://www.uknof.org.uk/uknof7/MacCarthaigh-Joost.pdf>
This article giving an initial analysis of Joost traffic is worth reading through (this one is based on some actual experiments)...
<http://blog.ipdev.net/2007/04/joost-analysis-of-bandwidth-hog.html" rel="nofollow"> http://blog.ipdev.net/2007/04/joost-analysis-of-bandwidth-hog.html >



Bob


____________________________________________________________________________
Bob Briscoe, <bob.briscoe@bt.com>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design