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 11:22 -0400, Greg Troxel wrote:

>> Why doesn't it just arrive when the phone is awake, from whatever
>> queue
>> it was in?
>
> It does.  But only when the PBX's TCP stack is ready to send it when
> it's most recent (backing off, remember) timeout expires.  By then, if
> the packet has been waiting a while in the queue, could be too long.

We're having terminology confusion.

What I mean is that the PBX sends an IP packet, and inside this packet
is a TCP segment, which contains an INVITE.  I am questioning if that
original IP packet eventually arrives at the phone.  I get it that the
TCP may retransmit, resulting in a new IP packet with perhaps the same
data, perhaps more.

So I am asking why that original packet is dropped and where.  That
seems like a bug.

>> 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
>
> No loss.  Just delay.

If the IP datagram containing the TCP segment is lost and TCP sends
again resulting in a new packet, then:

  There has been loss at the IP layer.

  There is no loss, just delay, at the TCP payload layer

because the loss recovery mechanism in TCP dealt with the IP layer loss.

My point is that things that smell like random loss that can be avoided,
should be avoided, rather than asking the loss recovery mechanism to
deal with them.

>> That's what the IETF draft is about.
>
> Right.  But has anyone actually implemented that yet?

I think so, but I don't know.  It's at -29, so I would be very surprised
if not.


>> 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.
>
> Why wouldn't they?  I would think it would have been completely
> expected, even designed for that if a link just goes silent, everything
> just waits for it to come back.

The systems do, but TCP does not.  The real question in systems design
is which feature is at which layer.  In modern wifi, there is layer-2
retransmission of packets, becuase the e2e retransmission mechanism is
not able to deal efficiently with true loss vs congestion, and because
it would result in packets having to cross the internet again with great
delay to be retransmitted on wifi.

At the time, telnet was used by humans, and mail was SMTP, which retried
with a new TCP connection.  The modern notion due to power saving that
an endpoint will routinely go away from minutes to hours and come back,
while the user of that endpoint wants prompt notification of incoming
messages, just didn't exist.

Hen the cell system has a packet for a phone, or an AP, it is buffered
until it is acked (it certainly is in wifi; it must be in cell or things
would be way worse than they are).  So the way power saving is done
should preserve that local reliability behavior, where the packet is
queued until it is handled.  So on wakeup there should be no need for a
retransmission.

>> You can do this.  But it's not bad to have an ICMP network
>> unreachable - just perhaps not what you want.
>
> I don't think I agree.  For my money, an ICMP network unreachable
> reflects a permanent lack of route somewhere.  Temporary outages should
> be silent and allowed to to resume when repaired.

You'll have to look up the IETF standards.  I think the issue is that
you don't want your TCP client to give up permanently on such a message,
not the message itself, and it probably does.

>> That's the intent of the new SIP/push protocol spec.
>
> But without any client and/or server implementations, we have to wait
> and do the best with what we have currently.

Sure. We just need to be clear that we are trying to make the best of a
situation where a good architectural solution is yet to come, and thus
there are different suboptimal choices.