4 ms·

They are breaking the TCP contract: "The server sends the first part of the response which we ack" I have seen this strange behavior on mobile networks: the s

They are breaking the TCP contract: "The server sends the first part of the response which we ack" I have seen this strange behavior on mobile networks: the server sends a heartbeat to a mobile client every 10 seconds, I pull the battery on the mobile client and still get an ACK for a minute or so. Now I have to bring the ACK up to the application layer so I know whether I am actually talking to the device, or the mobile network is lying to me.

wtallis 11y ago
They're breaking the TCP contract because they're strengthening the IP contract. When you've got a re-transmit facility sitting below TCP, it's reasonable to make some speculative promises. It's not reasonable to keep ACKing for a full minute or to ACK more than a handful of packets, though. But especially in the case where you've got more knowledge of the last-mile link's loss characteristics than the congestion control algorithm at the server endpoint, you can make some pretty nice bandwidth/latency tradeoffs.
- hinkley 11y ago
  True, they really should stop acking when they hit the window limit.
jsnell 11y ago
Performance enhancing proxies have existed (and have been deployed) for a long time. You will for example not find many, if any, satellite data providers without a PEP somewhere in the mix. Nor will you find many mobile operators who don't have a transparent HTTP proxy, even if not a generic TCP one. The implications of PEPs are discussed at length in RFC3135, and not really discouraged unless they interfere with the end to end principle on the application layer. For your specific example, using the ACK stream as a liveness signal isn't in general very useful. For example the kernel on the phone will happily continue ACKing for a long time even if the application that's consuming the data becomes wedged somehow and can't process it.

wtallis 11y ago

They're breaking the TCP contract because they're strengthening the IP contract. When you've got a re-transmit facility sitting below TCP, it's reasonable to make some speculative promises. It's not reasonable to keep ACKing for a full minute or to ACK more than a handful of packets, though. But especially in the case where you've got more knowledge of the last-mile link's loss characteristics than the congestion control algorithm at the server endpoint, you can make some pretty nice bandwidth/latency tradeoffs.

hinkley 11y ago
True, they really should stop acking when they hit the window limit.

jsnell 11y ago

Performance enhancing proxies have existed (and have been deployed) for a long time. You will for example not find many, if any, satellite data providers without a PEP somewhere in the mix. Nor will you find many mobile operators who don't have a transparent HTTP proxy, even if not a generic TCP one. The implications of PEPs are discussed at length in RFC3135, and not really discouraged unless they interfere with the end to end principle on the application layer. For your specific example, using the ACK stream as a liveness signal isn't in general very useful. For example the kernel on the phone will happily continue ACKing for a long time even if the application that's consuming the data becomes wedged somehow and can't process it.