Unreliable TCP?

Unreliable TCP?

[Ioan Ionita]

Hello.  I apologize if this may sound stupid/unknowledgeable.  I'm
currently fooling around with real time voice conferencing
applications which use the UDP protocol.  However, certain firewalls
don't allow UDP traffic, therefore I tried UDP over TCP as a
workaround.  This failed miserably, as the ACK aspect of TCP, which
delays everything when a packet is lost or received out of order makes
voice conferencing anything but real time.  So I was wondering if
there's any way to disable the whole reliability checking of TCP in
the linux kernel. Maybe configure the kernel to never request the
retransmission of a packet, even if it detects packet loss/bad order?
Thanks :)

Re: Unreliable TCP?

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1666 bytes --]

On Sat, 19 Mar 2005 21:59:16 EST, Ioan Ionita said:

> applications which use the UDP protocol.  However, certain firewalls
> don't allow UDP traffic, therefore I tried UDP over TCP as a
> workaround.

That's the firewall's problem, not yours.  There's very few firewalls
that prohibit *all* UDP traffic (for starters, DNS becomes interesting).
Usually a firewall stops *most* UDP traffic only because the firewall admin
has decided that there's few UDP-based applications that they want to allow
through...

Explain why you think that your application will be let through the firewall
if it's TCP-based?  If the firewall admin thinks enough of your application to
open a port, it's equally likely to get you an open UDP port.

(For bonus points, work out the ethics of trying to circumvent a firewall that's
there for presumably good reasons - the people who installed the firewall did so
because they only want to allow certain traffic through.  Having the user
ask "Can I have port 99343 opened so application XYZ works?" is much more likely
to be useful *LONG-TERM* than getting into a long-term pissing match with the
firewall admin, who gets upset at your attempts to bypass his firewall and
starts playing whack-a-mole.  If you *do* get UDP-over-TCP working, you're
looking at having to move the port around all the time because it will get
blocked...)

>                                             So I was wondering if
> there's any way to disable the whole reliability checking of TCP in
> the linux kernel. Maybe configure the kernel to never request the
> retransmission of a packet, even if it detects packet loss/bad order?

Yes, it's called UDP. :)


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Unreliable TCP?

[Willy Tarreau]

On Sat, Mar 19, 2005 at 09:59:16PM -0500, Ioan Ionita wrote:
> Hello.  I apologize if this may sound stupid/unknowledgeable.  I'm
> currently fooling around with real time voice conferencing
> applications which use the UDP protocol.  However, certain firewalls
> don't allow UDP traffic, therefore I tried UDP over TCP as a
> workaround.

I don't agree with this reason. One more valid reason could have been the
non-connected aspect of UDP which is not easy to manage through all
firewalls (timeouts, etc...). But all firewalls support UDP (eg: DNS).
If the firewall you're trying to bypass supports DNS, then encapsulate
your voice in DNS requests/responses, and when the admin complains, then
ask him to open another port.

>  This failed miserably, as the ACK aspect of TCP, which
> delays everything when a packet is lost or received out of order makes
> voice conferencing anything but real time.  So I was wondering if
> there's any way to disable the whole reliability checking of TCP in
> the linux kernel. Maybe configure the kernel to never request the
> retransmission of a packet, even if it detects packet loss/bad order?

If you disable retransmission, then some firewalls will sometimes block
because some packets will be out of window. And not only data are sent
in TCP, but control bits (SYN, FIN, RST) must not be lost. Some TCP
options such as window scaling will have a terrible impact if they are
lost and not retransmitted.

At most, you should lower the retransmit timeout. The 3s initial timeout
is far too high with todays local networks, and prevent real-time
applications from using TCP. However, if you use something like a few
tens or hundreds ms (depending on the RTT), you might get your voice
working on TCP.

Willy