On 16.06.2016 19:51, Tom Herbert wrote: > Transports over UDP is intended to encapsulate TCP and other transport > protocols directly and securely in UDP. > > The goal of this work is twofold: > > 1) Allow applications to run their own transport layer stack (i.e.from > userspace). This eliminates dependencies on the OS (e.g. solves a > major dependency issue for Facebook on clients). > > 2) Make transport layer headers (all of L4) invisible to the network > so that they can't do intrusive actions at L4. This will be enforced > with DTLS in use. > > Note that #1 is really about running a transport stack in userspace > applications in clients, not necessarily servers. For servers we > intend to modified the kernel stack in order to leverage existing > implementation for building scalable serves (hence these patches). > > This is described in more detail in the Internet Draft: > https://tools.ietf.org/html/draft-herbert-transports-over-udp-00 > > In Part I we implement a straightforward encapsulation of TCP in GUE. > The implements the basic mechanics of TOU encapsulation for TCP, > however does not yet implement the IP addressing interactions so > therefore so this is not robust to use in the presence of NAT. > TOU is enabled per socket with a new socket option. This > implementation includes GSO, GRO, and RCO support. > > These patches also establish the baseline performance of TOU > and isolate the performance cost of UDP encapsulation. Performance > results are below. > > Tested: Various cases of TOU with IPv4, IPv6 using TCP_STREAM and > TCP_RR. Also, tested IPIP for comparing TOU encapsulation to IP > tunneling.
Thinking about middleboxes again: E.g. https://tools.ietf.org/html/rfc6347#section-4.2.3 states that DTLS packets are not allowed to be fragmented. Because of this and furthermore because of the impossibility of clamp-mss-to-pmtu to work anymore, do you have any idea on how reliable this can work? Or is your plan to use a smaller MSS on all paths by default? Thanks, Hannes
