FWIW, #8 was raised when MPTCP was created - I pointed out that this system, like HTTP muxing, was doomed to needing to reinvent the whole of IP at the TCP layer (or HTTP layer, for HTTP muxing). That includes differentiated services.
Joe On 3/21/2018 10:10 AM, Aaron Falk wrote: > > Mark Handley sent this thought provoking note after our meeting this > morning. Some ideas here that stretch the architecture, I think. At > least we need to consider extensibility of the API. Forwarding with > permission. > > --aaron > > Forwarded message: > > From: Mark Handley <[email protected]> > To: Colin Perkins > <[email protected]>, [email protected] > Subject: Possible TAPS challenges > Date: Wed, 21 Mar 2018 14:27:40 +0000 > > Hi Aaron, Colin, > > As I mentioned, I'm playing with ideas for a new TCP-replacement > transport protocol at the moment. It doesn't really have a name > right now, but lets call it NeoTCP. Likely it won't go anywhere, > but some of the ideas differ a bit from other transport protocols, > so may serve as a useful test for the TAPS API. > > 1. Pre-authentication. I want to put the ssh server on my home > machine on the Internet without it being constantly attacked with > password guessing attacks. NeoTCP implements very simple > pre-authentication, where my laptop and my home machine share a > secret. When connecting, the client sends the pair (nonce, > Hash(nonce, secret)). The server won't send a syn/ack equivalent > unless the secret match one of the secrets from its cache. > > 2. Source-spoofing protection. NeoTCP supports the equivalent of > SYN cookies, but with a 4-way handshake to avoid the potential > deadlock associated with SYN cookies. I'm also playing with the > idea of allowing middleboxes to interpose a challenge in response > to the SYN, and when the challenge response arrives from the > client, only then is the packet passed through to the actual > server, and the handshake continues. I'm not clear yet if > including middleboxes in some way impacts the API. > > 3. Encryption. Goal is to do tcpcrypt-like encryption, but provide > hooks to higher layers so they can do whatever full authentication > that particular application needs. > > 4. Redirect. Redirecting connections is a very common > application-layer function, but really you would prefer to > redirect before you've set up a connection. Such redirection > obviously needs some form of authentication (maybe this > contradicts 3 - not clear where I'm going on this yet). What would > the API be for a redirect server? It's not a full server; it > listens, but simply sends stateless syn/ack redirects, rather than > accept connections. > > 5. Acking. NeoTCP supports multi-path using two sequence spaces - > subflow packet sequence numbers and data sequence numbers like > MPTCP. Unlike MPTCP, the data sequence number ack indicates the > receiving application received the packet (with MPTCP, it only > indicates reception by the receiving stack. > > 6. Pulling. NeoTCP takes some lessons from NDP, and is a > receiver-driven protocol. When several senders are sending to one > receiver, this allows the receiver to choose precisely which > senders to pull packets from at any time. This generalizes the > QUIC/HTTP2 priorities to now support multiple different senders. > You can use this to do aggregate congestion control for incoming > traffic, avoiding self-congestion. It's up to the receiving > application to determine priorities, and to the transport to > decide how to use those priorities. > > 7. Close is a total mess with TCP. It's even worse with a > user-space protocol - your application may quit when close > returns; data may not have been received yet and needs > retransmitting, but there's no-one left to do it. By default, with > NDP close won't return until the receiving application has > received sent data. Obviously you need some way to avoid deadlock > when the receiver died; that timeout is application specific. > > 8. Finally, we've done a lot of work over the last couple of years > on understanding MPTCP for web traffic. It's ugly. You have a > whole load of short objects, and the application has a priority > order for them. But the paths may have very different latency. If > you send any packet from the highest priority object on the high > latency path, you can delay the object significantly, and it can > really hurt the overall page load time, as other requests get > stalled waiting for that object. The best you can do is to run a > per-packet scheduler, and ask the question "if I send the next > packet from this object on the higher latency path, will it arrive > after the rest of the object sent on the lower latency path?" If > the answer is yes, you shouldn't send that packet on the higher > latency path. Next you have to consider the second highest > priority object, and ask if you should instead send a packet from > that object on the higher latency path. You should, if will arrive > before both the highest priority object and all the rest of the > second highest priority object. If not, you shouldn't, and you > should consider the third highest priority object, and so on. > Obviously, this is complicated. At the very least, the transport > protocol needs to know which packets are from which object, and > what those object priorities are. At the receiver, objects may > arrive out of order, but packets within an object must be in-order. > > There are probably more things, but that's what comes to mind > right now. > > Mark > > > > _______________________________________________ > Taps mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/taps
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
