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

[Brian J. Murrell]

On Sat, 2019-03-30 at 13:10 -0400, Greg Troxel wrote:
> 
> 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.

Roger.

> I am questioning if that
> original IP packet eventually arrives at the phone.

I can't know that.  I don't have any ability to packet-sniff on the
phone.  I can see that it leaves the PBX and makes it to the AP, but
beyond that I cannot be sure.

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

It presumably dropped in the air between the AP and the phone because
the phone is not in a state to accept it.  But that's not a bug any
more than an IP packet can fall out of the end of a strand of sliced
fiber or a broken ethernet cable.

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

Yes.

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

Yes.

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

Agreed.

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

If the endpoint is sleeping and not in a state to accept a packet, that
loss is unavoidable.

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

Right.

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

Sure.

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

I think power saving is more like a(n accidentally, for example) broken
medium, like a sliced cable.  But on purpose.  That analogy feels more
accurate, to me.

Cheers,
b.

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