Some few follow-up comments; I think my points are clear for the other ones.
> > Maybe it would help to me to better understand the deadlock if I had > a > > concrete example. > > Okay, here's a simple example. Both sides set send and receive buffers > of 8192 bytes using SO_SNDBUF/SO_RCVBUF. Then both sides write 16384 > bytes. Then both sides read 16384 bytes. Under vanilla TCP, this is > deadlock-free because the sending kernel and receiving kernel each > buffer 8192 bytes not read by the application. > > All I'm saying is that I'd like such scenarios to continue to be free > from deadlock under tcpinc. They might already be under all existing > proposals. Or if they aren't, you might already agree with me that > this > would have to be fixed in any proposal, in which case your confusion > might be why I'm mentioning such an obvious point. Only because I > can't > tell if all the proposals have this. OK, I think we agree that there are no *known* deadlock issue right now assuming reasonable implementations. And we also agree that all specifications have to address how to deal with small send/receive buffers. > > As far as I know, SO_SNDBUF/SO_RCVBUF is the *socket* buffer size, > > which should not be affected if tcpinc offers a socket interface to > > the app, as far as I understand it. > > > > But the socket buffer may not be the buffer TCP uses - if they were > > the same, this would be a specific implementation choice. > > > > The TCP buffer can be larger. For instance, I think Linux uses for > TCP > > buffering a buffer significantly larger than the socket buffer: > > Well, then this requires some investigation. For instance, on at least > some variants of BSD, SO_RCVBUF directly affects the advertised window > size. So perhaps this discussion should be detached a bit from > SO_SNDBUF/SO_RCVBUF. The higher-level point is that scenarios that > don't deadlock on particular implementations of vanilla TCP should > continue not to deadlock when tcpinc is enabled. Indeed. This could imply that those BSD variants may have to change their 1:1 mapping of SO_RCVBUF to the advertised receive window. I don't think any IETF specification mandates this - the IETF does not standardize the sockets interface. Many other stacks use much more sophisticated algorithms to set the advertised receive window. > > tcpcrypt seems to have to violate TCP flow control for INIT1/INIT2 > > (well, using EDO could possibly solve this problem). > > We would ideally specify a reasonable minimum window size (like 500 > bytes). If it turns out that the window is independent of SO_RCVBUF, > then this is easy just to mandate it. Possibly EDO could help, too, > though ideally tcpinc would benefit from but not be blocked by other > proposals. I am not sure what you mean by "blocked". Do you mean that TCPM may not complete the EDO spec fast enough? If so, please come to TCPM and help us moving forward at least the non-SYN case. We really look for feedback from implementers of EDO right now. Or is your concern the risk that EDO could be blocked on a number of Internet paths by middleboxes, thereby reducing the number of path over which tcpinc would work? If so, please speak up in TCPM as well. In particular, I think TCPM would be highly interested in insights about middleboxes that block the current EDO design but that would let through the current tcpcrypt design. My own concern is that the INIT1/INIT2 mechanism seems to define an own, special long option encoding format that appears to be incompatible with EDO and the other encoding variants currently discussed in TCPM. Not only ideally the IETF should avoid having several incompatible TCP long option formats designed independently of each other. Interoperability could become a real mess, in particular if we would try to further extend any of the mechanisms in the upcoming years. Thanks Michael _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
