Re: [Linphone-users] Why Android (Oreo) phones, are actually less reliable with TCP vs. UDP

[Brian J. Murrell]

On Sat, 2019-03-30 at 10:30 -0400, Greg Troxel wrote:
> 
> What I meant is just as you said it, which is that the phone gets a
> wakeup message, and then connects to the server and gets whatever
> information is to be sent.

That's one way.  The FCM message can carry a payload for the
application to just consume.  This could be the case for IM
applications for example where the FCM payload could carry the message
to be sent and the IM application just displays that message without
contacting it's own server.

But the payload could be encrypted for the privacy conscious.

> What I think was happening as you described slowness with TCP was
> that
> the phone had a TCP connnection, and in a world that didn't have
> power
> saving that requires FCM, the server would just send things over that
> connection and they would arrive.

Right.

> But, the combination of having TCP that is expected to work, power
> saving that means it does not work, and FCM wakeups mean that we
> have a sequence
> 
>   phone sets up connection to server
>   phone goes to sleep
>   server sends data
>   server sends push
>   phone wakes up
>   (now what)

Phone waits for server to retry sending the data after the TCP-retry-
wait has expired.  For non-time sensitive data, this is fine.  The data
will arrive when the TCP-retry-timeout expires.  For time sensitive
data, not so fine.

>   phone sets up connection to sip server
>   phone registers with push server and gets a token
>   phone sends token to sip  server and tells it it is entering push
> mode
>   phone disconnects from sip server
> 
>   phone goes to sleep
> 
>   server gets call and send wakeup via push server
> 
>   phone gets wakeup from push server
> 
>   phone connects to sip server and does a reconnect
> 
>   sip server sends INVITE

Yes, this of course would be much better.  This of course requires the
SIP server to understand this "going to sleep, wake me when you need
me" message.

> Certainly I never heard the notion expressed.  At the time TCP was
> invented, endpoints weighed more than people and needed rooms with
> air
> conditioning!

Indeed.  But I don't think the networks were as reliable as today. 
Just guessing.

> And if
> it
> went away, there'd be a new TCP connection to retry mail in hours.

In fact, TCP survives network outages, as long as nothing in the path
does something bad like sending an ICMP message reflecting the network
outage.  I used to do this over dialup all of the time.  I'd ssh
somewhere, phone line would drop, I'd bring it back up the next day and
ssh just resumed.

> It's not really the guarantees but the retransmission rules that
> avoid
> congestion collapse.

Right, but the retransmission (rules) is part of providing the
guarantee.

> So, protocols that are going to be used with clients that have this
> deep
> sleep mode have to be aligned with how that works, and I think that
> more
> or less means not sending data to the client when it's in deep sleep,
> which means the push registration sequence above.

Don't disagree.  A system where all parties know the state of the other
parties and accordingly, and we don't have some parties pretending to
be in one state when they are not, would be ideal.

> Technically true of course.  Do sip servers and clients usually do
> DTLS?

Probably not.  I was just saying it's not like it doesn't exist.

> It's been becoming yesterday's problem for 20 years.  In another 10
> years we'll be there!

I personally experience it broadly enough that it's "here" for me.  :-)

> But not firewall brokenness.

This is true.  They still need to track state.

Cheers,
b.

signature.asc
Description: This is a digitally signed message part