Subject: [ledbat] Correcting misinformation in RFC5290

From: Bob Briscoe <[email-masked]>
Date: Fri, 13 Nov 2009 02:20:41 +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" <[email-masked]>, "ALLMAN,
Mark" <[email-masked]>

From: Bob Briscoe <[email-masked]>

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

[
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>

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>

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/>.

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>

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> (Find
"MaxConnectionsPerServer" within the page)

<
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>

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

Bob

____________________________________________________________________________

Bob Briscoe, <[email-masked]>
Networks Research Centre, BT Research

B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5
3RE,UK.    +44 1473 645196

________________________________________________________________

Bob
Briscoe,
BT Innovate & Design

---

From: Stanislav Shalunov <[email-masked]>
Date: Fri, 13 Nov 2009 13:51:14 +0900

Bob,

As a procedural note, if there's inaccuracy in RFC5290 (I just read  
s3.2.2 and it sure looks like there's a mistake), we're not chartered  
to update that.  The mistake comes from a forum post http://forums.macosxhints.com/showthread.php?t=67237 
  and is a result of imprecise terminology of that forum post combined  
with confusion about licensing limits for a particular application and  
the OS's limits on the ability to open TCP connection.

We should obviously only put correct information into the WG draft,  
and we're free to cite RFC5290 if appropriate, but we can't and  
shouldn't supersede it or even cover the heart of the flow-based  
fairness discussion in that RFC.

The best place for the correction for posterity is at the citable  
source, RFC5290.  The RFC editor does not currently have any errata  
for RFC5290 (http://www.rfc-editor.org/errata_search.php?rfc=5290&rec_status=15&presentation=table 
).  Errata for individual submissions can also go straight to the RFC  
editor.  If you were to correct the mistake in an erratum, which  
requires a specific text edit, it can be submitted as described at http://www.rfc-editor.org/how_to_report.html

If the erratum is verified, future references to RFC5290 would be  
referring to a document with this known erratum.

Even if we were to put a correction into the WG draft without  
deprecating RFC5290, it'd be hard to find for anyone who encounters  
RFC5290 on itself -- harder than an erratum, for which at least  
there's search by RFC number.

Does that sound like a reasonable way to proceed?

-- 
Stanislav Shalunov
BitTorrent Inc
[email-masked]

personal: http://shlang.com

On Nov 13, 2009, at 11:20 AM, Bob Briscoe wrote:

> 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" <[email-masked]>, "ALLMAN, Mark" <[email-masked]>
>> "                                 ...
>> 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).
>> 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>
>> 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>
>>
>> The XP Pro license says:
>> 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/ 
>> >.
>>
>> 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>
>> 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> (Find  
>> < http://support.microsoft.com/kb/282402> (Note the limp caveat at  
>> the bottom of the page)
>>
>> 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>
>> 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 >
>>
>>
>>
>> Bob
>>
>>
>> Bob Briscoe, <[email-masked]>      Networks Research Centre, BT  
>> Research
>> B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44  
>> 1473 645196
> Bob Briscoe,                                BT Innovate & Design
>
> _______________________________________________
> ledbat mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ledbat

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 13 Nov 2009 14:31:35 +0000

Stas,

Yup - much better process idea.

Bob

At 04:51 13/11/2009, Stanislav Shalunov wrote:

Bob,

As a procedural note, if there's inaccuracy in RFC5290 (I just read
s3.2.2 and it sure looks like there's a mistake), we're not chartered to
update that.  The mistake comes from a forum post

http://forums.macosxhints.com/showthread.php?t=67237 and is a result
of imprecise terminology of that forum post combined with confusion about
licensing limits for a particular application and the OS's limits on the
ability to open TCP connection.

We should obviously only put correct information into the WG draft, and
we're free to cite RFC5290 if appropriate, but we can't and shouldn't
supersede it or even cover the heart of the flow-based fairness
discussion in that RFC.

The best place for the correction for posterity is at the citable source,
RFC5290.  The RFC editor does not currently have any errata for
RFC5290
(
http://www.rfc-editor.org/errata_search.php?rfc=5290&rec_status=15&presentation=table
).  Errata for individual submissions can also go straight to the
RFC editor.  If you were to correct the mistake in an erratum, which
requires a specific text edit, it can be submitted as described at

http://www.rfc-editor.org/how_to_report.html

Even if we were to put a correction into the WG draft without deprecating
RFC5290, it'd be hard to find for anyone who encounters RFC5290 on itself
-- harder than an erratum, for which at least there's search by RFC
number.

--

Stanislav Shalunov

BitTorrent Inc

[email-masked]

personal:
http://shlang.com

Reinaldo,

Bob

To: "FLOYD, Sally"
<[email-masked]>, "ALLMAN,
Mark"
<[email-masked]>

From: Bob Briscoe
<[email-masked]

Sally, Mark,

Off list.

"
...

[
P2P].

..."

More

----

<

<

The XP Pro license says:

Win 95/98 had a limit to the TCP/IP stack of 100 concurrent connections,
but that was configurable via the registry <

-----

<

<

<

<

<

Bob

Bob Briscoe,
<[email-masked]

Bob
Briscoe,
BT Innovate & Design

ledbat mailing list

[email-masked]

Bob
Briscoe,
BT Innovate & Design