"Scharf, Michael (Michael)" 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 directions without deadloc
"Scharf, Michael (Michael)" 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 still don't understand wh
Martin Thomson writes:
> On 14 August 2015 at 11:05, David Mazieres
> wrote:
>> If we don't specify requirements for the session ID, then applications
>> will have to be knowledgeable about what encryption spec they are using.
>> That means if we get large SYN options down the line and massively
Mirja K=C3=BChlewind 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 information in the tcp-eno opti
Tero Kivinen writes:
>> This is doable, though adds complexity to implementations. Should this
>> tie-breaker be sent by every active opener (and therefore consume option
>> space), or do you imagine that applications intending to use
>> simultaneous open set an option to include the tie breake
Eric Rescorla writes:
> I think we're finally getting to the place where we have been
> misunderstanding each other. We have some mechanism in the signaling
> which attempts to break the symmetry and assign one side as A and one
> as B. If that mechanism works, then no signaling in TCP is
> neces
Hi, everyone. We've released a new draft of TCP-ENO, available in the
usual place:
https://datatracker.ietf.org/doc/draft-bittau-tcpinc-tcpeno/
In this draft, we've tried to address all of the feedback we received on
the list. Some suggestions we incorporated directly. In particular:
Bryan Ford writes:
> - Section 2, Introduction: insert “, if needed by the negotiated
> protocol,” somewhere appropriate in bullet 6 at the very end of this
> section.
That bullet says, "so as to name each end of a connection for encryption
or authentication purposes." So what if it's needed fo
I just posted a new draft of TCP-ENO, available here:
https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpeno/
This reflects the issues discussed in Berlin, as well as the first cut
at data in SYN segments. Note that these changes are all open for
discussion, I just think that the disc
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
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 acknowledge the SYN data...
>
>
>
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
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) algorithms for key agreemen
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 fro
14 matches
Mail list logo
