Exceeding connection limit

[Scott Bennett]

     On Fri, 05 Dec 2008 13:14:08 +0100 Dominik Schaefer <schaedpq2 at gmx.de>
wrote:
>Scott Bennett schrieb:
>>      I still don't understand this.  I will try to find time to resume
>> reading those proposals, but the idea of running stream data over a protocol
>> with neither sequence preservation nor reliable delivery would be a good
>> thing goes against all of my experience. For one thing, it would mean that
>> those things would involve wheel-reinvention inside tor to support those
>> characterstics of TCP not supported by UDP.
>As far as I understand: Tor does not have to do any reliable delivery and
>error correction at all, because that can all taken care of a level higher
>(Tor being layer 3, the network layer and TCP layer 4, the transport layer).
>Suppose an application communicates via TCP: then all error correction and
>checking can be done by the TCP connection tunneled through Tor, not Tor
>itself. If a packet is lost in Tor, it is no different to a packet-loss within
>any other network. And in case of UDP through Tor it would be anyway someone

     Really?  What about all of tor's internal communications for establishing
and tearing down circuits, streams, etc.?  Also, I guess I don't know enough
about tor's chosen encryption methods, so I have to ask, is any kind of hash
or other residue from encrypting the data in a cell used in encrypting the
data in any cells transmitted later?
     BTW, I know a lot of people seem to do it, but using OSI layer numbers
isn't really valid with an IP-based stack.  Not all layers are equivalent
between the two architectures.

>elses problem as well. Tor does not have to ensure a guarenteed and correct
>delivery any more than other networks do.
>Actually, it is a bad idea to tunnel TCP connections through TCP connections,
>due to two interfering error corrections. Detailed explanation at: Why TCP
>Over TCP Is A Bad Idea, http://sites.inka.de/sites/bigred/devel/tcp-tcp.html
>
     Yeah, I get that, but it seems to me that some sort of duplication of
overhead *is* necessary because tor's connections are *not* the same as the
connections tunneling through them.  Different interests are involved (i.e.,
tor's vs. the interests of the various unknown applications running connections
through tor's connections).  TCP over TCP indeed has performance problems,
but obviously it does work.  Using SCTP for tor's connections might be a
better way to support users' tunnels.
     The more I read about SCTP, the better it looks.  It has an option to
provide, effectively, RDP, which has never been implemented in the past, so
that is an obvious alternative to UDP to consider if one goes the unsequenced
route.  It allows multihomed connections, which allow increased data rates,
potentially quicker early responses while allowing better Internet routes
discovered later to be used to improve performance on already opened links.
Multistreaming is built into it.


                                  Scott Bennett, Comm. ASMELG, CFIAG
**********************************************************************
* Internet:       bennett at cs.niu.edu                              *
*--------------------------------------------------------------------*
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."                                               *
*    -- Gov. John Hancock, New York Journal, 28 January 1790         *
**********************************************************************