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