Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Weaver]

[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]

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

[ejs]

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?

[Weaver]

[aesmith]

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.

[Weaver]

Indeed. Quite so.

[ejs]

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?

[Weaver]

[niemand]

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.

[Chrysalis]

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