Re: [quicwg/base-drafts] What can change in a different version (#55)

[Brian Trammell <[e-mail]>]

On counterargument one: IMO the most important lesson to take from the transition from Cisco NetFlow version 9 to IPFIX (the latter was based on the former) is that the transition pain for existing deployments tends to be *greater* when the wire formats are more similar. "Break it once, then don't break it again" would have been much less painful than the "oh so that header diagram looks almost the same so I can safely ignore the rest of the text, there certainly aren't any subtle semantic differences to worry about there" transition that we got. 

On counterargument two: not sure I follow... is the argument here that we *want* it to be hard for middleboxes to "find" the connection ID? I personally think this counterargument perilously underestimates the human ingenuity (or, if you'd like a negative expression, "sheer unmitigated gall") of middlebox designers, as well as the flexibility of VHDL as a programming environment for expressing hardware packet inspection. We can force there to be a predictable processing cost for this information through an encoding, or by making the connection ID the answer to a puzzle, but doing this through random offsets simply increases middlebox designer annoyance while increasing the potential of hard-to-debug processing errors in middlebox implementations (i.e. operator annoyance) more.

This is probably purely ideological: I just don't see the point of deciding to expose a thing, then making it pointlessly difficult to use. There *may* be a discussion to be had about encoding information exposed in the wire image as puzzle solutions, in order to make targeted diagnostic usage of these fields possible while making mass usage of them (e.g. for all QUIC flows crossing a network border) costly. However, if we select the set of things to expose properly, and design the semantics of connection ID properly, such mass usage would tend to be useless for nefarious purposes (tracking, surveillance) while still being useful for less nefarious purposes (proactive detection and/or localization of network performance issues).

-- 
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/55#issuecomment-269744431