[Standards-JIG] Re: What happened to the ACK proposal?

Tijl Houtbeckers thoutbeckers at splendo.com
Tue Aug 16 20:31:08 UTC 2005

On Tue, 16 Aug 2005 20:06:07 +0200, Ian Paterson  
<ian.paterson at clientside.co.uk> wrote:

>> On the "internet" you can't assume that the TCP
>> connection you make is a straight end to end TCP connection.
> Hmm, sorry I didn't know that. (I was probably not paying attention to
> the previous thread.) This should be mentioned in JEP-ACK.

Well, the example I often named here is GPRS acces point, that  
transparently buffer your data (and ACK the sender). In some cases after  
data gets send into the "black hole" here, these even "hijack" the  
connection to "properly" close them after a time out.

Another case where you can really count on things like this to happen, is  
explicit tunneling, such as SOCKS proxies which many Jabber clients  

Some other cases I've seen or heard (or well.. written), port forwarding  
programs (mostly windows based ones, not the standard linux stuff),  
internet sharing programs, my old crappy cable modem (!!!)..

Basically anything that gets touched by the Berkely style socket API, or  
the even higher level APIs (java io/nio, a lot of scripting languages,  
etc.) is at risk since it can make it either hard or impossible to  
correctly forward TCP data. This won't change any time soon.

Apart from that there are the networking products that refuse to do it  
right for their own reasons. The trend here I think is, that this will  
(and has) improve(d) since I looked at this some years back espc. because  
the appliance market has settled on some established stacks (linux amongst  
them) that do this the way you'd expect them to it. However my troubles  
with GPRS kit (which is a relativly new technology) seem to suggest we've  
not seen the last of this.

So if you're lucky, you have a clean "path" to the server. I'd say that's  
still in most cases by far, even if you're using NAT and firewalls and  
what not. The problem is, there is no way to detect when you're dealing  
with an "edge case" (if you like) like that.

It's just not very realistic right now to expect people to use TCP for  
100% reliable hop to hop (hops from the XMPP perspective) communication.  
That they don't have the tools for it (the API) is one, and if you ask me,  
still the most compelling.
The other is that, as explained, When you get a TCP ACK you can only be a  
100% sure, that the next hop has received your packet (hops from the  
TCP/IP point of view) and "taken responsibility" for it. Wether that means  
all the other hops after that have done the same already, you just can't  
be sure. It should mean that, but in practise....
With JEP-ACK we basically take that same principle, but suddenly it's  
applied at the XMPP level! Not a bad improvement..

> Assuming this is true, then the case for XMPP ACK is very compelling
> (the problem won't go away even if people upgrade their TCP stacks). Why
> didn't this point carry the argument last time?

Well, it was mentioned both before and after JEP-ACK was rejected.

More information about the Standards mailing list