[Standards-JIG] Re: What happened to the ACK proposal?
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
> 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