[tcpinc] (Ideally) final draft 14 of TCP-ENO posted

Version 14, which I hope can be the final draft of the TCP-ENO specification, has been posted here: https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpeno/ Thanks very much to everyone who provided reviews and feedback. We have attempted to incorporate all the comments we received

Re: [tcpinc] new drafts of TCP-ENO and tcpcrypt

Gregorio Guidi writes: > Having followed the standardization of tcpcrypt on the tpcinc mailing > list (as a passive observer), I wanted to check with you on a point > that was not heavily discussed as far as I can see: the choice of the > "mandatory to implement" (MTI)

[tcpinc] New TCP-ENO draft posted

A new TCP-ENO draft is available in the usual location: https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpeno/ It should address all of the comments received so far in last call, most of which are just wording improvements that were already discussed on the list. Given how small the

Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno

Wesley Eddy writes: >> If a host sends a SYN-only SYN+ENO segment bearing data and >> subsequently receives a SYN-ACK segment without an ENO option, >> that host MUST reset the connection even if the SYN-ACK segment >> does not

[tcpinc] Andrea Bittau

I'm incredibly sad to report that Andrea Bittau died in a motorcycle accident on Saturday. Andrea was one of the most cheerful and likable people I've ever met. He was also a brilliant engineer, undaunted by the most intimidating challenges. I've never known anyone as good as him at diving into

Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01

Mirja K=C3=BChlewind mirja.kuehlew...@tik.ee.ethz.ch writes: Hi David, I believe the point is, if you have already broken the tie via out-of-band signal and both endpoints have already decided who will be the opener (host A) and responder (host B), why do you still need to write this

Re: [tcpinc] Selective protection of services provided by TCP headers

Scharf, Michael (Michael) michael.sch...@alcatel-lucent.com writes: It doesn't have to be an issue, but it can be an issue if a protocol is not properly designed. And naively attempting to address the problem could lead to other issues (such as exceeding the receive buffer size). Sorry, I

Re: [tcpinc] Selective protection of services provided by TCP headers

Scharf, Michael (Michael) michael.sch...@alcatel-lucent.com writes: * Deadlock freedom and buffer space control. TCP implementations provide control over buffer space via socket options such as SO_SNDBUF and SO_RCVBUF. Applications should be able to send data simultaneously in both