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

Tijl Houtbeckers thoutbeckers at splendo.com
Tue Aug 16 16:24:57 UTC 2005

On Tue, 16 Aug 2005 17:13:53 +0200, Ian Paterson  
<ian.paterson at clientside.co.uk> wrote:

> This is a problem with the implementation of TCP. The application should
> be told as soon as the previous ACK fails to appear within the
> configured time.
>> That's what you get for using a protocol designed for
>> interconnecting networks over high-loss physical
>> connections as your transport layer. Ain't the Internet
>> grand?
> This case does not highlight a problem with TCP. It highlights a problem
> with bad TCP implementations (which unfortunately seem to be the norm).

I know this point has been raised many many times in the past, but since  
the same can be said from this whole discussion, maybe it's worth  
mentioning again. On the "internet" you can't assume that the TCP  
connection you make is a straight end to end TCP connection. Also, TCP has  
no mechanism for discovering this, or a standerdized mechanism for carying  
peer to peer information over multiple hops.

So what stops us from using XMPP reliably in this aspect, is not just  
"broken" TCP implementations, but indeed "broken" networks that we have to  
deal with. Unfortunatly the internet is very "broken" indeed by these  

> XMPP devolves to the transport layer responsibility for a) confirming
> delivery over a hop, and b) detecting broken connections. XMPP isn't
> supposed to know or care which transport layer is being used. Should RFC
> 3920 be changed just because implementations of TCP are bad?

By those criteria, we can only conclude that the current TCP binding is  
incorrect by design. TCP simply offers no such garantuees. To quote from  
RFC 793, page 9:

   An acknowledgment by TCP does not guarantee that the data has been
   delivered to the end user, but only that the receiving TCP has taken
   the responsibility to do so.

What is comes down to is many implementations of intermediate "hops"  
(transparant or not) only use ACK to maintain a good flow and garantuee in  
order delivery. And with good reason, maintaining a garantueed delivery  
state using ACKs would make the life of an intermediate "hop" a lot harder  
(issues like data bursting would lead to either larger queues, more risk  
of timeouts, or a slower flow, escp. with nasty TCP window sizes).

This means in practise, even if you fix all socket APIs to suddenly expose  
ACK events (when you think about all this, you might get an idea why they  
haven't bothered with that so far), you can only trust TCP as far as the  
next hop, which is not far enough.

So what's harder to change? The council's opinion of a JEP? the XMPP RFC?  
Or the entire internet?

When it's agreed the current TCP binding is unreliable (I can't think of  
any other serious protocol that relies on it either), then why not have  
the binding on the stream level? I haven't heard any good reason to put it  
a level lower yet. TCP is not the only inreliable transport layer, so for  
the reuse potential alone the JEP-ACK concept sounds better to me. I think  
noone so far suggested it should be mandatory either.

More information about the Standards mailing list