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 09:40 -0400, Greg Troxel wrote:
>> 
>> The FCM way is, I think, for the client to reconnect and query, with
>> the
>> server not having pushed anything.
>
> I'm not sure I'm completely understanding what you are saying.
>
> The FCM way is that information server/services that want to send
> something to an app -- this can be instant messaging, etc. -- send it
> to the app via an FCM push.  This is done by the server sending an API
> query to the FCM service identifying the phone that it wants to send
> the payload to and the payload it wants to send.  In the case of IM
> type applications, this message from FCM can have what the service
> wants to send, or it can simply be a "hey, come to me and get your
> message".  The latter is how linphone is using it.

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.

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.  This is how many things on my phone
work, including XMPP and IMAP.

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)

so now we have async retransmits happening.

Instead, I think the FCM (or any oob push; this is not about the
non-free/tracking issue of FCM) way is:

  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

so there there is no timing race between retransmit and everyting else;
things are only sent on channels that are expected to work.

>> But in this case I think it's about working around a system that
>> isn't processing packets correctly in a way that none of this was
>> designed to handle.
>
> That's not an unfair statement.  Even though TCP was invented so long
> ago that networks were inherently unreliable, I doubt it was imagined
> that endpoints would be so transient as phones are getting to be today.

Certainly I never heard the notion expressed.  At the time TCP was
invented, endpoints weighed more than people and needed rooms with air
conditioning!  From the early days of the ARPANET, the network was
mostly there (or it was uucp when it was mostly not there).  And if it
went away, there'd be a new TCP connection to retry mail in hours.

I first saw wireless lan interfaces in the late 90s.  Even then, there
was no real notion of keeping a TCP connection alive across network
disconnects as the normal approach.

I think it's only recently that we are seeing the aggressive power
saving of turning off wifi and ignoring incoming data on a TCP
connection.

> It's mostly workable though.  Most things don't need the kind of timely
> delivery that SIP does and so a bit of TCP-retry-delay backlog goes
> unnoticed.  But some protocols like SIP really do need timely delivery
> and so the guarantees that TCP provides actually hinders it.

It's not really the guarantees but the retransmission rules that avoid
congestion collapse.  If most traffic were UDP we'd need the same rules
to avoid congestion collapse.

But what I'm trying to say is that in a world where IP packets can be
buffered for times that are longer than a few seconds, any
retransmission plan is troubled, as retransmission strategies have to
try to cope with ambiguity between congestion and loss, and then would
have to cope with ambiguity among congestion, loss, and delay.

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.

>> I see the TCP/UDP connection issue as having two larger points:
>> 
>>   TCP can and should use TLS, to hide the username and password in
>>   register messages
>
> TLS does not require TCP.  DTLS is TLS over UDP.

Technically true of course.  Do sip servers and clients usually do DTLS?
Is there some STARTDTLS sort of thing that happens on port 5060?  I have
never seen this in config in a client.

>> TCP seems more likely to traverse possibly multiple layers of perhaps
>> broken firewall and NAT devices.
>
> Yes, this is true.  But fortunately, becoming yesterday's problems. 
> IPv6 is coming, and arriving.  I have 3 IPv6 connections to the
> Internet on my consumer services.  Two are with ISPs and one is an IPv6
> tunnel.  My mobile provider gives me IPv6 addresses.  It also gives me
> IPv4 with broken NAT so I actually prefer IPv6.

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

> But all of the brokenness of NAT goes away with IPv6.

But not firewall brokenness.    I've had to set keepalives on TCP to
keep firewalls from timing out ssh connections.

>> Yes, UDP ought to work, but I think it's more likely to lose with
>> broken devices, and that's part of the source of the notion
>
> I'm not sure I buy a prevalence of broken UDP devices either though. 
> Surely not saying they don't exist, but I don't think they exist to the
> level of FUD about UDP that seems to float around here.

I haven't been tracking the FUD.  I would only say that TCP with
keep-alive data of some sort every 15 minutes is overwhelmingly likely
to work (because if it doesn't the network is just plain broken), and
that TCP that is quiet for longer, and UDP, is somewhat more likely to
be broken.  I would not say it's usually broken.

But, unless DTLS works almost everywhere (and one can easily configure
the client and server to not allow cleartext registration), then TLS
seems to be the only reasonable approach.