On 30/03/2015 19:23 pm, Tim Shepard wrote:
Surely the better direction would be to move towards what TCP does? We
are fundamentally talking about TCP, so its methods and manners should
dominate, no?
Most discussions I have seen about the low level framing of TLS &
friends indicate it is wildly complicated and overdone, and something to
distance from in new designs, not emulate.
(Although to be fair, I'm not really sure what this entails beyond the
catch-all phrases of TLV & TCP. And, I'm not even sure I agree with
imposing TLV over all of tcpinc. It opens the door to "flexibility" aka
complexity, whereas tightness and purpose is better in my mind.)
Where you in the WG meeting (or listening in remotely)?
No, 'fraid not.
My
understanding of the consensus in the room was that using TCP's
framing for tcpinc would make tcpinc too brittle in the face of
middleboxen which resegment the TCP connection (despite having let
the initial options through where we negotiated tcpinc on).
Hmmm ok - thanks for that, so at least there is a positive reason.
Yes, we
all agree they those middleboxes shouldn't be doing that, but the
desire to make tcpinc continue to work through those sorts of boxes
mandates that we not use TCP's framing but do our own framing in-band
(within the bytestream carried by TCP).
I see that there might be an issue here, although I do not see why the
muddleboxen would breaking the framing, no matter which method is used.
And the tcpcrypt folks
agreed to respin their proposal with in-band TLV-like framing.
Yes, saw that, in the minutes. Just didn't understand why.
I guess the tcpfolk have seen the evidence of this and have the handle
on it and how this new framing solves the problem. If it is just a
matter of handling framing that trips up middle boxes, then fine.
If however it is a matter of "becoming more compatible with TLS" this is
an oddity that is beyond my comprehension...
thanks again.
iang
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
