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

Tijl Houtbeckers thoutbeckers at splendo.com
Thu Aug 18 09:12:28 UTC 2005


On Thu, 18 Aug 2005 02:37:16 +0200, Ian Paterson  
<ian.paterson at clientside.co.uk> wrote:

>> 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.
>
> Thanks for the interesting in-depth response. :)
>
> Ian plays the devils advocate:
>
> XMPP is likely to be an important protocol for mobile service providers
> - some are already encouraging their subscribers to use XMPP instead of
> SMS. Mobile network conditions are just as likely to delay a JEP ACK
> ping response as a TCP ACK.

Well, technically seen they don't delay the ACK, they actually speed it  
up. You get an ACK before it's even tried by someone or something to  
deliver the TCP packet. I don't see why they would do such things on the  
XMPP level (I don't see any technical benefit to it). Maybe when they map  
it to some other protocol (wireless village) and there is no equivalent.  
However, since both client and server would likely be in their own hands  
in that case, that's not even a problem.

> In either case the server would drop the
> XMPP connection, reducing the QoS. So isn't it possible that those
> mobile service providers currently subverting TCP ACK will do the same
> with XMPP ACK for similar reasons? (Especially since JEP ACK will result
> in up to a 100% increase in XMPP packets transferred over the mobile
> network.)

Well, I don't seem how they can filter out ack packets *on* the client, so  
in that case it'll use the most precious part of their network anyway.  
They might intercept and destroy them coming from the server to the  
client, if they ever get that pity they are gonna mess up higher level  
protocols too. I don't see a technical benefit (which I do see for the APN  
gateway ACKing packets instead of the handset, though they could use  
different techniques if you ask me) and I don't see them doing this in a  
cheap way either.

> Anyway, it's good to hear that Internet TCP is, in general, improving.
> Do you know whether UMTS kit features the same problems? GPRS is rapidly
> being replaced by UMTS so, going forward, we should be more concerned
> with UMTS. (XMPP ACK might take some time to define, implement and
> deploy.)

I just got a new UMTS device, so maybe I can do some testing later. That  
is, after it stops refusing to read any data at all on the socket or HTTP  
request I open (no doubt what I send to it gets a neat ACK though).



More information about the Standards mailing list