Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I suspect that a lot of innovation energy moved to QUIC, because with TCP your nice new variant can be randomly nobbled by middleboxes. For example, see https://blog.apnic.net/2021/12/08/efficient-multipath-transp...


QUIC is a step backwards here; it has no multipath support: https://lwn.net/Articles/964377/

Multipath: There are several areas where TCP still has an advantage over QUIC. One of those is multipath support. Multipath TCP connections can send data on different network paths simultaneously — for example, sending via both WiFi and cellular data — to provide better throughput than either path permits individually.

Server connection migration is explicitly forbidden by QUIC:

https://github.com/quicwg/base-drafts/pull/2031


The draft multipath extension is here: https://datatracker.ietf.org/doc/draft-ietf-quic-multipath/

It's on the standards track, rather than experimental, so likely to be supported once finished. There seem to be some implementations, including Apple:

https://github.com/quicwg/multipath/wiki/QUIC-Implementation...


QUIC is a step back, IMHO. Especially, given how many national networks work poorly with UDP protocols.


If QUIC adoption grows, that will motivate network providers to improve UDP performance and connectivity


Nobody cares about those middleboxes, those are only relevant in corporate networks.


Such middleboxes can also be seen in cellular networks. (And firewall in free access points / guest networks)


>Such middleboxes can also be seen in cellular networks.

Complain to your ISP if they mingle with a layer they are not supposed to mingle with.

>(And firewall in free access points / guest networks

I consider those as "corporate".




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: