[Standards] Use of XEP-0198 resumption under adverse network conditions

Thilo Molitor thilo at eightysoft.de
Sun Nov 8 11:36:41 UTC 2020

Georg, you seem to forget the push that is involved.

I think most of your depicted problems would go away if the client would send 
a (XEP-0198) ping upon receiving a push and, if that ping does not succeed, 
decide that the connection is dead.
That way it won't stick to an old half-dead connection but still use that old 
connection if it remained usable.

No second stream needed in this scenario.

- tmolitor

Am Freitag, 6. November 2020, 18:41:15 CET schrieb Georg Lukas:
> Hi Dave,
> * Dave Cridland <dave at cridland.net> [2020-11-04 12:48]:
> > TL;DR: When the session has a ping timeout, do push notifications, but
> > otherwise leave it open - mobile clients will often recover after several
> > minutes have passed.
> That's a great analysis and I haven't considered this situation yet, but
> your proposal sounds very logical to me.
> I see two potential issues:
> the client needs to mirror this logic as well, and stick to an old TCP
> session for a much longer time. I fear there will be some pathological
> situations where it will render the client effectively disconnected,
> e.g. when the old connection gets blackholed, but a new one could be
> established any time.
> Furthermore, some long time ago I've seen situations where a TCP
> connection had a very hard time recovering from intermittent packet
> loss, where the connection's latency remained very high and throughput
> very low. Did you experience this effect as well, or is this just a
> faint memory from times of much worse congestion control algorithms?
> To solve either problem, I can imagine that a client *could* open a
> second stream to the server in parallel to the existing one, and if the
> second stream completes authentication, then just 0198-resume there.
> But this is also going to increase medium contention, and it's even more
> sockets for the client to juggle around.
> Georg

More information about the Standards mailing list