Re: [ledbat] Correcting misinformation in RFC5290

[Stanislav Shalunov <[e-mail]>]

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
[e-mail]

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" <[e-mail]>, "ALLMAN, Mark" <[e-mail]>
>> From: Bob Briscoe <[e-mail]>
>> 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, <[e-mail]>      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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ledbat