[Standards-JIG] Re: What happened to the ACK proposal?
ian.paterson at clientside.co.uk
Thu Aug 18 10:29:27 UTC 2005
> > 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:
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.)
> 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 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
More information about the Standards