I don’t think this is a new idea. The real issues are single sided deployment and breaking assumptions middleboxes on the network make. RFC1693 was my first hit on google I imagine this space has been explored.
Of course, I’m ignoring fiddly details like segment boundaries, interactions between this strategy and
flow- and congestion-control, and so on. It’d take a lot of work to really do this!
To experiment with this you could use SCTP with partial reliability. I am not sure if you could still use a stream socket in the same way you would use a TCP stream socket, it might be interesting to play with.
I’m imagining this in the context of websockets, where you are stuck with TCP only. But in that context, you can’t control the browser’s TCP stack making retransmit requests, and usually streaming is from a server to a browser… So I’m not quite sure how this can be applied. It is clever, though.
I don’t think this is a new idea. The real issues are single sided deployment and breaking assumptions middleboxes on the network make. RFC1693 was my first hit on google I imagine this space has been explored.
To experiment with this you could use SCTP with partial reliability. I am not sure if you could still use a stream socket in the same way you would use a TCP stream socket, it might be interesting to play with.
I think the part I’m missing is why use TCP if you don’t want its features?
I’m imagining this in the context of websockets, where you are stuck with TCP only. But in that context, you can’t control the browser’s TCP stack making retransmit requests, and usually streaming is from a server to a browser… So I’m not quite sure how this can be applied. It is clever, though.
Because that’s how the Internet is. TCP works pretty much every time, but UDP doesn’t.
Relevant presentation: http://dedis.cs.yale.edu/2009/tng/papers/pfldnet10-slides.pdf