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

Dave Cridland dave at cridland.net
Fri Nov 6 20:42:59 UTC 2020

On Fri, 6 Nov 2020 at 17:41, Georg Lukas <georg at op-co.de> wrote:

> 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.
I'm not sure that's true - primarily because a client is free to decide to
try a new connection at any time, an option the server does not have

The client also is more likely to know what's happening at the physical
layer (or what passes for the physical layer these days).

We've broadly not seen problems with existing sessions on the same medium
(ie, without a Wifi/4G change) where a new session would solve the problem.

> 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.

I think if the client has got as far as decided the TCP socket is
unrecoverable at its end, it can just spin up a new session.

If it cannot ping with the existing connection, it will not be able to
establish a new one if the existing one is potentially recoverable, and

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20201106/d033e701/attachment.html>

More information about the Standards mailing list