Internet > General Internet

Tunnel over TCP

(1/3) > >>

Weaver:
[I get the feeling that I have asked about this before, if so sincere apologies.]

A tunnelling protocol that uses say TCP is usually considered a very bad thing and met with a shudder. Acknowledging ACKs with ACKs is frowned on. There is a danger of performance collapse in the face of high levels of retransmissions, iirc?

I am not sure, but I think there might be a way to avoid some of the problems by appropriate design.

The reason I was thinking about ‘over TCP’, or even ‘over SCTP’, which would be better, was that I wanted a way of getting rid of all MTU issues, not making them worse. Allowing a jumbo transport interface down a tunnel, so for example you could send 8kB or nearly 9kB long packets over a tunnel interface accessed across a LAN or much longer packets if the current endpoint interface was o/s-internal, within the current box itself.

aesmith:
I think the issue with tunnelling TCP within TCP is that you can end up duplicating retransmissions, depending on timers.   Another way of looking at it is that you have a reliable payload, so don't need a reliable tunnel.  Or vice versa of course.  I wonder if it could be worked around by tweaking timers so the tunnel retries and retransmits before the funnelled connection "realises" there's a problem.   Or if you're writing the protocol, an unreliable version of TCP for the tunnel, effectively as if it had an infinite window size.   I presume your idea is that you could tunnel full sized packets since TCP is a stream, and the packets don't need to fit within the MSS but can overlap into successive packets.

Weaver:
Indeed. I seem to remember something about some software that de-encapsulated TCP and sent the payload itself rather than taking IP PDUs that contain TCP and handling them as any general kind of unknown packet. Reduces header overhead too, I would imagine, if done properly. As a general idea it would need to be redone again and again for every kind of retransmitting L4-L7 to fully fix the problem 100%. For example, you would need an SCTP-aware recogniser/handler module too de-encapsulate SCTP, and so on and so on. But that still makes it better than just not bothering to do anything.

Since all I am really interested in is how to fully fix the reduced MTU problem, and then some, I would prefer other approaches, ones that are L4-ignorant/agnostic or whatever the cliché is I’m looking for. You could treat that idea as a kind of accidental data compression, which is a very good thing.

I wonder though if there are very good solutions to be found that just fix the MTU problem by a type of intelligent fragmentation also coupled with the reverse and combined with header compression using per-channel muxing or dictionary/index compression or who knows what.

Someone ought to have done a superbly efficient and well-behaved tunnelling system that gives 100% or even better performance, better because of really really well done idiomatic compression and completely gets rid of the MTU problem. The reason I thought about the accursed and widely condemned (with reason) approach of tunnelling using TCP (or even SCTP) is that at least you do not end up reinventing the wheel trying to do your own reliable link from scratch, or else worst of all forget that the L3 path you are using is unreliable and end up with protocol bugs. The other advantage of using TCP is firewall, o/s and intermediate node compatibility, which is very much on the feature list for some tunnelling systems. I can see why some designers have taken silly things like http as the basis for their implementation. Or even ssh.

ejs:
I don't think it makes any sense to attempt to fix any MTU issues with a tunnel. All any kind of tunnel is going to do is move the problem somewhere else. I don't think you can fix an MTU issue by mangling the packets somehow at your end.

I think a very clear description of what MTU issue(s) you are attempting to fix might help.

Weaver:
A tunnel interface is what's required. Clearly you can't fix an mtu problem when you have already created it, that makes no sense.

Navigation

[0] Message Index

[#] Next page