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

Tijl Houtbeckers thoutbeckers at splendo.com
Thu Aug 18 12:01:16 UTC 2005


On Thu, 18 Aug 2005 12:29:27 +0200, Ian Paterson  
<ian.paterson at clientside.co.uk> wrote:

>> > 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.
>
> Yes. I meant that, if the mobile operator didn't subvert TCP then the
> ACK from the handset would be delayed.
>
>> I don't see why they would do such things on the
>> XMPP level (I don't see any technical benefit to it).
>
> You mentioned that ACKs are fabricated to "maintain a good flow". I
> assumed the APN gateway does that to hide the delays from the server -
> giving it the confidence to send more packets instead of resending the
> same packets, or even closing the connection due to lack of TCP
> responses. What I tried to say was:

Yes.. it might even be redoing the layout of TCP packets (changing the  
sizes or something). Maybe some retransmission magic? I have no idea what  
the exact motivations are, nor what whether all kit does this, or just the  
ones I've actually investigated at the packet level (and I have no idea  
what vendor was used when I did, which may be the same one every time I  
did test). However from experience I know you can keep sending very large  
amounts of data onto a socket without application noticing till eventually  
the socket times out. (my reason for investigating this at the time). But  
as is clear in this discussion, the causes for that be numerous, and a  
combination of bad factors (like a bad API and a large TCP window size)  
can send lots of data to the "black hole" even if all ACKing works as  
you'd expect it.

> If the server doesn't receive a timely response to its XMPP <ping/> then
> it would close the connection. So I am asking if it is possible that
> mobile operators *might* subvert XMPP by programming their APN gateways
> to generate XMPP <pong/> responses? (An additional benefit might be that
> if the APN gateway produces the JEP ACK responses then they will save up
> to 50% of the XMPP packets transferred over their mobile network.)

Well, 25%, since they can only stop what goes *to* the client. Even less  
if more data is received (fairly typical with Jabber) than sent, because  
the client acks each stanza received, and the telcos can't stop those acks  
till after they've travelled across their precious spectrum.

>> 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)
>
> What could they do instead?

I think spoofing a larger window size would have the same effect. The  
"tcp" on the other end would keep sending packets even if they are not  
received by the handset, and the APN can keep a buffer. However, like I  
said, I don't know their reasons. It's understandable they do *something*  
though, because TCP would be a horrible performer otherwise, in this  
variable bandwith, variable latency, high loss enviroment. Even with just  
1 handset involved, let alone two talking to each other.

Note that on the other side (java handset to network) you have the  
blackhole problem anyway (if you use the TCP binding), since the API of  
the few 100 millions of phones out there that support sockets (however,  
not all networks do either, so sometimes HTTP is the only option, which  
has it's own problems where JEP-ACK would be usefull) is very much like  
the normal Java API (just stuff it in an outputstream and never hear from  
it again).

>> I just got a new UMTS device, so maybe I can do some
>> testing later.
>
> That would be very interesting. UMTS is so much faster than GPRS that
> perhaps the APN gateway will have little need to hack TCP in default
> mode? I'm hoping the people responsible for the network problems are
> resolving them?

They do the most idiotic things, so I'm not counting on them. I'm glad if  
they allow me a TCP connection in the first place.



More information about the Standards mailing list