obonaventure / draft-tcp-converters Goto Github PK

Based on ether pad

• 0-RTT TCP Converter
  https://tools.ietf.org/html/draft-ietf-tcpm-converters-00
  Speaker: Olivier Bonaventure

Lars: Do you insert the IP address in the payload, rather than the DNS name?
Olivier: We currently insert the IP address (for speed). We could add a TLV for the DNS name, too.
Matt: Are you aware of the window scale option and the rounding errors that can result with large windows?
Olivier: We can discuss offline.
Matt: Has there been discussion of interactions with TLS?
Olivier: You need to rely in server CERTs. This does not change things, TLS works at the payload, it only impacts the bytestream.
Yuchung: I do not understand the motivation. The most useful MPTCP is to solve the parking lot problem. This does not seem to match the cellular/wifi multipath usage. What are key examples of use cases?
Olivier: A proxy could be put in the operator, and runs in the network. The ISP provides both wifi and cellular case.
Yuchung: This seems not common in the US. Do many ISPs provide cellular and wifi?
Olivier: Many networks provide this. There are examples in RFC8041.
Jonathon Looney: I found tension between the idea of a client specifying extensions, whereas the client has less control on the conversation between converter and the server.
Oliver: The original goal was to support MPTCP, we have not yet looked at other options and plan to do this in the future.
Jonathon Looney: This seems like a form of middlebox, and we need to avoid the normal pitfalls. (There are considerations we need to address and identify issues / problems. Example: Measurements with timestamps.)
Oliver: This type of convertor is really explicit. We will make sure we explain this and extend the middlebox section.
Mirja: A big difference I see is that you open an end-to-end connection to the convertor.
Praveen: What about the errror cases - with DDos/validating the client source address. Does it relay all TCP packets?
Oliver: We only send a SYN+ACK once it has seen one from the server. To be sure the connection is established.
Praveen: How do you relay DDoS prevention that retransmits SYNs. This one IP address seems to open lots of conenctions from the convertor.
Oliver: The server has a block of IP addresses that it uses (this will be clarified in the ID).
Jake Holland: What happens when teh client has multiple paths - some of which do reach the convertor?
Oliver: The client can try muiltiple paths and see which suceeds (bootsrap done), it uses these.
Tim Shepherd: Is the convertor inside sometimes inside the OS - does an app need to be reworked to do this?
Oliver: This is a little like a SOCKS proxy.
Bjoern Metzdorf : What happens if the client addresses change and you own a TFO cookie? E.g. in a load-balanced server.
Oliver: You may keep a table, and you may have "sticky" behaviour that keeps working with the same client. The convertor knows how to manage the lieftime of the cookies it has. Special care is needed for load balancing servers.
Yuchung: A walk-through of how this works would be really useful as an example. Focusing on a setup.
Oliver: We could provide one example in an appendix (there are really many scenarios)
Yoshifumi: Can this be implemented in user space or does it require kernel-space modifications?
Olivier: It requires kernel-space work. There are three implementors I know about, and we will talk.