Just one QUIC bit
I was in the IETF meeting.  It was actually a very civil discussion, and I think almost everyone in the room could see both sides on the issue.  On the one hand, we've seen increasing problems with middleboxes making assumptions about end-to-end protocols, and this making it very hard to then deploy new end-to-end functionality.  The problem is real; we measured this effect in this paper:http://www0.cs.ucl.ac.uk/staff/M.Handley/papers/extend-tcp.p...Indeed, one of the changes the IETF group has made since taking on QUIC is to also encrypt the QUIC sequence numbers, so middleboxes can't play silly games by observing them (they were already integrity protected).However, the flip side is that network operators do use observations of network round trip time gained from passive observation of traffic so as to discover if traffic is seeing excessive queuing somewhere.  An inability to do this with QUIC may either lead to worse network behaviour, or to them using other methods to gain insight.  If you're in a location where you can observe both directions of a flow, you can easily do this by, for example, delaying a bunch of packets by 200ms, then letting them go.  When you see a burst of (encrypted) ack packets return, you can deduce the RTT from your observation point to the destination.  I'd really like to avoid operators thinking they need to do such hacks just to measure RTT, and the spin bit lets a passive observer see the RTT.In the end, I was not convinced entirely by either argument, and neither was the consensus in the room.  It's not a clear-cut decision; there are reasonable arguments either way.  Such is engineering.