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

[Greg Troxel]

"Brian J. Murrell" <address@hidden> writes:

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

"could"??  Principle of least privilege says MUST.  And even leaking the
payload length is not ok for some.  (But I see what you mean.)

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

Agreed that this could happen this way.  But why is the TCP packet lost?
Why doesn't it just arrive when the phone is awake, from whatever queue
it was in?  What is the mechanism by which it is dropped?

As I see it, this is a suboptimal system design, relying on a loss
recovery mechanism to retry when there is not actual loss in the usual
sense, instead of having a plan to avoid loss


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

That's what the IETF draft is about.


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

They weren't, but there was congestion loss which was erratic, and they
were flaky where they would not work for a long time.  Nobody expected
TCP connections to survive these needing-repair or wet-phone-line kind
of outages.


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

You can do this.  But it's not bad to have an ICMP network unreachable -
just perhaps not what you want.

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

Yes, but there are retransmission rules inside applications that use
UDP.  My point is that retransmission is used - regardless of where
located - to provide guarantees, and the same retransmission has to
avoid congestion collapse.   Which is trivial if the scheme is
responsible for effectively no traffic.

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

That's the intent of the new SIP/push protocol spec.

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

DTLS exists, and IPsec.  But it seems the only practical way to encrypt
SIP signalling is TLS/TCP.

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

Have you turned off v4?  How does that work for you?

Or do you just  mean you can talk to your sip server over v6 just about
always?  That I can believe.