21–30 of 105 posts
Earlier quoted context omitted.
The point is that QUIC is supposed to be fully encrypted below the UDP layer. The question is why add bits in the clear on top of this to water it down and open an avenue for potential abuse.
Yes but it doesn't really say why anyone wants this spin bit. What are they going to do with it? Measure RTTs? Why? What for?
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/…
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/…
Realistically, are network operators going to add artificial delay to packets going through their network? If they don't get their bit, and they start slowing down communication, it would seem like market correction would solve it.
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/…
Realistically, are network operators going to add artificial delay to packets going through their network? If they don't get their bit, and they start slowing down communication, it would seem like market correction would solve it.
Personally, I don't want them to expose anything. The RTT on my packets is yet another piece of metadata capable of being abused.
In addition, I hope that the whole QUIC thing is a nice reboot of actually getting end-to-end connectivity back on the Internet so we can get some protocol experimentation moving again.
Earlier quoted context omitted.
The point is that QUIC is supposed to be fully encrypted below the UDP layer. The question is why add bits in the clear on top of this to water it down and open an avenue for potential abuse.
Yes but it doesn't really say why anyone wants this spin bit. What are they going to do with it? Measure RTTs? Why? What for?
My personal stand is to prohibit exposing any metadata on the connection whatsoever, but given the counterarguments, I don't think the proposed solution is ideal.
As someone only superficially familiar with networking, I think it would be interesting to know what impact the current packet inspection practices by the middleboxes have on network performance. After all, the article mentions that those middleboxes want to control the message flow and use that as justification. The assumption behind QUIC seems to be that there's no "global" benefit in that specific kind of network…
well, all (almost ?) current boxes can do that at line rate for minimal sized packets.
> incentives of the middleboxes to inspect packages(sic)
incentive is for charging / billing / steering packet flows etc.
It seems to be a fairweather metric: OK resolution when the network is operating normally, but providing no useful information when something has gone wrong (which is when you'd want it most).
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/…
Realistically, are network operators going to add artificial delay to packets going through their network? If they don't get their bit, and they start slowing down communication, it would seem like market correction would solve it.
Earlier quoted context omitted.
Realistically, are network operators going to add artificial delay to packets going through their network? If they don't get their bit, and they start slowing down communication, it would seem like market correction would solve it.
I've no idea what techniques will actually be applied by operators - I never expected middleboxes to go to the extremes they currently do either. But the technique I mentioned, of briefly delaying a short burst of packets, if done only occasionally, isn't really going to be noticed during a large transfer. I'm not claiming its a good idea though!