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
_______________________________________________ Linphone-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/linphone-users
