Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
   Glossary   Glossary
 
Please login or register.

Login with username, password and session length
Advanced search  

News:

Author Topic: Tunnel over TCP  (Read 3194 times)

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Tunnel over TCP
« on: May 19, 2018, 06:11:23 AM »

[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.
Logged

aesmith

  • Kitizen
  • ****
  • Posts: 1216
Re: Tunnel over TCP
« Reply #1 on: May 22, 2018, 01:00:14 PM »

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.
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Tunnel over TCP
« Reply #2 on: May 22, 2018, 01:30:58 PM »

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.
Logged

ejs

  • Kitizen
  • ****
  • Posts: 2078
Re: Tunnel over TCP
« Reply #3 on: May 22, 2018, 07:29:40 PM »

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.
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Tunnel over TCP
« Reply #4 on: May 22, 2018, 11:01:30 PM »

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.
Logged

ejs

  • Kitizen
  • ****
  • Posts: 2078
Re: Tunnel over TCP
« Reply #5 on: May 24, 2018, 07:26:55 PM »

That goes back to my second point:

I don't think you can fix an MTU issue by mangling the packets somehow at your end.

What exactly is this MTU problem that you are trying to solve?
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Tunnel over TCP
« Reply #6 on: May 25, 2018, 04:26:25 AM »

I'm not trying to solve anything for myself. It’s a design study, exercise.
Logged

aesmith

  • Kitizen
  • ****
  • Posts: 1216
Re: Tunnel over TCP
« Reply #7 on: May 25, 2018, 12:56:06 PM »

I understand the idea.   Currently most if not all tunnels carry the tunnelled packets on a one to one basis, meaning that the tunnelled data's MTU is reduced to allow space for the additional tunnel headers.  However if you tunnelled using a streaming transport there's be no need.  Payload packets could be spread over any number of tunnel packets.   Simple example the first tunnel packet might carry 3/4 of a payload packet, next one has the last 1/4 and 1/2 of the next packet etc.
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Tunnel over TCP
« Reply #8 on: May 25, 2018, 01:50:49 PM »

Indeed. Quite so.
Logged

ejs

  • Kitizen
  • ****
  • Posts: 2078
Re: Tunnel over TCP
« Reply #9 on: May 25, 2018, 08:10:59 PM »

So what MTU issue(s) is this design study supposed to be solving then?

Or is the whole idea to have a connection to a server hosted somewhere that can chop up packets however you like, and you can put them back together at your end?
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Tunnel over TCP
« Reply #10 on: May 26, 2018, 02:12:03 AM »

No, your application that uses large MTU on a jumbo frames LAN can take to transferring stuff over a multi-hop path by using software virtual interfaces at the endpoints, that is in the same box as the application, or across a jumbo LAN only one hop away. This gives you a transition mechanism to eventually end up with a large native path MTU network.

You could just need a tunnel anyway for other reasons. But if you have to have one, having a large MTU is a great attraction on your tunnel’s spec sheet.
Logged

niemand

  • Kitizen
  • ****
  • Posts: 1836
Re: Tunnel over TCP
« Reply #11 on: May 26, 2018, 12:42:13 PM »

My employer's product already does this. Combination of https://tools.ietf.org/html/rfc1191 and own fragmentation and reassembly algorithms.

Use methods to establish link MTU then use MSS clamping to ensure TCP segments are the correct size. Where protocols do not have an MSS use own encapsulation, fragmentation and reassembly to break large packets down and reassemble them on the other side.

If running a tunnel you obviously have endpoints either side of it so it's not a problem to do this.

So this is already a done thing from a number of vendors. It's basically offloading the overhead of fragmentation, reassembly, etc, from the endpoints to an intermediate device and is usually used for things like replication tasks where an FCIP blade appears to use jumbo frames, the actual transport being abstracted by a tunnel.

Using TCP inside TCP isn't really a thing from this point of view. Usually you'll be wanting your own proprietary protocol for other purposes so may as well incorporate the functions of TCP you need into that and encapsulate in UDP, GRE or something else.

In the case of our software GRE, UDP, IPSEC over UDP (NAT-T) and AH/ESP are available. When transporting TCP we will place it inside something else and, depending on conditions, either have the host and server layer 4 session untouched or run a TCP proxy to improve throughput.
Logged

Chrysalis

  • Content Team
  • Addicted Kitizen
  • *
  • Posts: 7382
  • VM Gig1 - AAISP L2TP
Re: Tunnel over TCP
« Reply #12 on: May 26, 2018, 01:25:40 PM »

yeah openvpn can do this disable encryption and set TCP as protocol
Logged