On Jan 9, 2008 8:15 AM, coderman <[EMAIL PROTECTED]> wrote: > ... the DTLS proposal hasn't seen any attention lately
things i would add to a revised DTLS proposal in my copious free time: - preserve TCP support while converting all traffic to DTLS; use airhook [0] like library for transparent TCP, SOCKS, and reliable Tor messaging (signalling channel). - use a virtual machine implementation to avoid timer resolution and event dispatch latency in win32, in addition to traffic shaping (pf or tc) on the VM for outgoing DTLS control and transport traffic. UDP, TCP and name resolution could then be supported transparently to the user/host os while running on a fast event based unix implementation in vm. traffic shaping is going to be critical to keeping latency low (buffers on broadband CPE devices can incur up to 1-2 seconds of latency when send queue is maxed out...) - UDP NAPT busting, including symmetric and full cone UDP NAPT detection and assisted simultaneous open. UPnP would of course be just as useful for UDP port assignment as for TCP... - the TCP support could be kept in place for bridge nodes, as DTLS Tor will stick out like a sore thumb on a network. the "Web HTTPS" looking sessions to bridges would be useful when UDP/DTLS is blocked. :) 0. Airhook - Reliable, efficient transmission control for networks that suck. http://airhook.ofb.net/ * this is likely to be useful in a Tor DTLS environment, as it is for wireless, because most TCP stacks are going to treat the intermittent lag / packet loss of the multiple DTLS hops as "congestion", leading to poor throughput. this is similar to the situation with wireless where temporary congestion or 802.11 timeouts are treated as "congested network" by most TCP stacks, rather than just "less than ideal wireless network".