4 ms·

Not sure how you arrived at flat rate being the only alternative. It's almost trivial to count ingress only for host flows to which the customer's device respon

Not sure how you arrived at flat rate being the only alternative. It's almost trivial to count ingress only for host flows to which the customer's device responds positively (say, by replying using anything except ICMP or a TCP error)

tjoff 14y ago
Does any ISP do that though? I've never heard of it, then again I haven't had contact with any ISP delivering external IPs to mobile connections. The point about battery remains though. And the solution you propose can easily be exploited to allow unlimited data for say, video streaming.
- hosay123 14y ago
  In Saunalahti's case they differentiate by offering different connection speeds, all at flat rate. I'm not really sure if what I suggested is implemented anywhere, just playing devil's advocate. :) One possible solution might be to combine it with stateful filtering, dropping a unidirectional ingress flow after some number of packets if the device never responds. My point was mainly that something must be broken if the customer is getting billed due to the environment beyond their control. In the case of power management I'm not sure it's that simple, it's at least true that the HTC Dream would not usually respond to pings while the display was off (haven't experimented with other devices). Presumably the application processor only awoke when a kernel timer fires, which only applies to client sockets the device itself created. Actually it makes sense that random inbound data traffic wouldn't wake the phone, otherwise you risk your OS getting a bad reputation because of some crappy telcos sending ARP every 1 second or something.
  - tjoff 14y ago
    I agree that it is unreasonable, and is a bit shocked that there are countries where receiving an sms can cost you money... But a reasonable solution to incoming data is to enable NAT, it isn't much of a hinder for a tech savvy user and is otherwise better for the 99.99% of the users. My phone (Nexus S) always responds to the pings I send. Which kind of makes sense, the default is to have a constant connection to google anyway (so that it can receive any push messages). Apparently google already made the decision that it is worth the battery drain. And android has already gotten plenty of bad reputation for applications misbehaving. While I'm sure some telcos are misbehaving in all ways imaginable as well it is probably nothing compared to the apps users gladly install for themselves.
    - hosay123 14y ago
      > something must be broken if the customer is getting billed due to the environment beyond their control. This is what happens when you debate random tangential topics online while hung over.. so basically I had no point to make, and you made me realize NAT is a pragmatic solution to the imaginary problem I'm complaining about. > Presumably the application processor only awoke when a kernel timer fires And of course for the reasons you point out, this presumption was obvious nonsense. :) Now I'm not sure what caused the behaviour I saw on the Dream.
bdonlan 14y ago
I wouldn't call it trivial - you'd need a stateful firewall (not necessarily a NAT) to keep track of which network flows are active. It would also be exploitable - you could open a TCP control connection to host X, and have host Y stream you data over UDP, to which you never reply directly, but rather use the host X control connection to ack the data.

tjoff 14y ago

Does any ISP do that though? I've never heard of it, then again I haven't had contact with any ISP delivering external IPs to mobile connections. The point about battery remains though. And the solution you propose can easily be exploited to allow unlimited data for say, video streaming.

hosay123 14y ago
In Saunalahti's case they differentiate by offering different connection speeds, all at flat rate. I'm not really sure if what I suggested is implemented anywhere, just playing devil's advocate. :) One possible solution might be to combine it with stateful filtering, dropping a unidirectional ingress flow after some number of packets if the device never responds. My point was mainly that something must be broken if the customer is getting billed due to the environment beyond their control. In the case of power management I'm not sure it's that simple, it's at least true that the HTC Dream would not usually respond to pings while the display was off (haven't experimented with other devices). Presumably the application processor only awoke when a kernel timer fires, which only applies to client sockets the device itself created. Actually it makes sense that random inbound data traffic wouldn't wake the phone, otherwise you risk your OS getting a bad reputation because of some crappy telcos sending ARP every 1 second or something.
- tjoff 14y ago
  I agree that it is unreasonable, and is a bit shocked that there are countries where receiving an sms can cost you money... But a reasonable solution to incoming data is to enable NAT, it isn't much of a hinder for a tech savvy user and is otherwise better for the 99.99% of the users. My phone (Nexus S) always responds to the pings I send. Which kind of makes sense, the default is to have a constant connection to google anyway (so that it can receive any push messages). Apparently google already made the decision that it is worth the battery drain. And android has already gotten plenty of bad reputation for applications misbehaving. While I'm sure some telcos are misbehaving in all ways imaginable as well it is probably nothing compared to the apps users gladly install for themselves.
  - hosay123 14y ago
    > something must be broken if the customer is getting billed due to the environment beyond their control. This is what happens when you debate random tangential topics online while hung over.. so basically I had no point to make, and you made me realize NAT is a pragmatic solution to the imaginary problem I'm complaining about. > Presumably the application processor only awoke when a kernel timer fires And of course for the reasons you point out, this presumption was obvious nonsense. :) Now I'm not sure what caused the behaviour I saw on the Dream.

bdonlan 14y ago

I wouldn't call it trivial - you'd need a stateful firewall (not necessarily a NAT) to keep track of which network flows are active. It would also be exploitable - you could open a TCP control connection to host X, and have host Y stream you data over UDP, to which you never reply directly, but rather use the host X control connection to ack the data.