On Mon, Mar 12, 2012 at 11:57 AM, Mike Perry <mikeperry@torproject.org> wrote:
... Your ideas intrigue me and I wish to subscribe to your newsletter.
my last comment for this sad, confused tangent of a thread; it has been accosted via conjecture with too much frequency *grin* SCTP for congestion control of transparent proxy TCP/UDP traffic. local classification of traffic allocates by protocol / use fairness instead of aggregate tcp fairness. like bittorrent or aria2 parallel traffic treated as distinct low priority unit of traffic, deferring to higher priority low latency web traffic and messaging. multi-homing / multi-path endpoints in SCTP would maintain concurrent connection with distinct endpoints, avoiding predecessor, timing, denial of service attacks present in reliable, ordered, single stream transports. edges would be screwed as you mention, unless they were full fledged participants consistently. using a UDP based transport with LEDBAT or other technique to keep broadband upstream unsaturated and unclogged (no deep queues), allowing all broadband endpoints the ability to contribute to a large shared network. ORCHID IPv6 addressing with IPsec tunnels is intended to re-use existing work, including well tested auth+privacy with datagram padding in IPsec. SCTP+TLS would fit over top of IPv6 ORCHID endpoints (using IPsec SAs) to transport signalling/keying and encapsulated client traffic. part of this would also include lowest priority (lossy reliable) SRMP type delivery of useful, less immediate information to nodes. to some extent the ORCHID addresses could be thought of as hidden service names and also circuit endpoints for a given IPsec tunnel. this set of: a. critical signalling and keying traffic b. high priority, interactive web traffic and messaging c. lower priority bulk traffic, downloads, streaming media d. best effort, latent bulk caching and exchange are the classful shaping groups ordered inside of opaque SFQ outbound queues at various improved/concurrent stratified dependent link padding paths of IPsec telescopes carrying intermediate hop(signalling) and bearer traffic. combining better prioritization of traffic and consistent consumption of traffic (deferring low priority packets and using opportunistic caching strategies for network information respectively) obtains the best performance out of the SFQ DLP paths with the lowest latency for priority traffic. still, so many details left as exercise for the reader ;)
Do free reference implementations exist for all of these protocols?
sort of, for only parts; if you want a portable user space implementation (or port) it's all custom. the joys of wild conjecture include absurd timelines and technical effort for free... rump is about as close as i've seen: http://www.netbsd.org/docs/rump/index.html this is not the least of "how to deploy a thing like this" concerns. there is also no backward compatibility or slow transition from an existing Tor network to something using UDP encapsulated IPsec telescopes (even if TCP can be transparently proxied over SCTP over this). _______________________________________________ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE