NNSquad - Network Neutrality Squad
[ NNSquad ] Re: ISP's resetting RealPlayer?
Cutting people off, or "charging by the gallon" for that matter, are only reasonable (and would only be acceptable in the context of power, water, or any other conventional utility) if specific rules are known to subscribers in advance and -- *very* important -- if proper notification is given before taking actions. Even if people don't pay their power, water, phone, or cable bills, they're given notification and time to argue their case before they're cut off -- at least in this country. What ISPs are frequently doing is acting as judge, jury, and executioner at the *data* level, often based on vague and general statements in Terms of Service agreements -- leaving subscribers to wonder, as in the cases under discussion, how or if they violated a rule or limit, or whether they're being affected by some totally different technical issue unrelated to purposeful ISP actions. The argument that explaining the detailed rules and limits in advance would provide too much information to subscribers who might try to take "excessive" advantage of those limits is unacceptable. If Comcast, for example, felt that they needed to manipulate P2P traffic for the sake of all customers, they should have made this clear in advance, and not denied what was going on until they got caught red-handed. One critical issue related to Network Neutrality isn't really a technical matter at all. It's the obvious need for full transparency in ISP dealings with their subscribers. Without that, all other efforts are likely doomed to inefficacy. It is in fact largely the lack of such transparency -- and unfortunately, trust as well -- that has made this project necessary in the first place. --Lauren-- NNSquad Moderator - - - > > >You didn't quote the whole question, or relevant information. Ron said: > > > >"On some days I have no problem at all with the connection to NPR, which > >makes me believe that the reset is not coming from the content provider. On > >other days I regularly get a connection reset every hour or so." > > > >If the audio servers were setup to drop streams that were up for a period of > >time, the behavior would be deterministic. > > Human listeners' behavior is not deterministic. Some programs are popular; > others are not. More people listen on some days than others. > > >> The terminated sessions may also be the result of the use of a stateful > >> firewall. When there are lots of long term connections, the tables in the > >> firewall can fill up. It may be forced to throw out state information -- > >> especially when the transaction is being conducted via UDP (which isn't a > >> session-oriented protocol, though RealPlayer uses it as such). When you're > >> going through a NAT firewall there can be no guarantee that UDP port > >> translation will be maintained over an extended period. It would be > >> interesting to see if your connections were still terminated if you used > >> TCP instead. > > > >This is total bunk, if you know anything about how stateful firewalls work. > > I've written them, and it is not. > > >TCP sessions are stateful because of their connection-oriented nature. UDP > >connections are pseudo stateful in that firewalls will keep state > >information for a set amount of time for UDP connections. If there is no > >traffic between the hosts and ports for the timeout period, the firewall > >would time out the "state" of the UDP connection. It is very deterministic. > > No, it's not. Often, the router will drop information on the oldest aliased > port when the table fills. We see not only consumer but also enterprise routers > that do this. > > >> On the other hand, many ISPs do limit the durations of sessions. People > >> often leave streaming media on and then go home -- for the evening or even > >> for days at a time. If large numbers of people do this (and as an ISP I > >> can tell you from our statistics that it's quite common), it can consume > >> excessive resources. It doesn't help that streaming audio consists of lots > >> of small packets, maximizing network overhead and causing congestion. > >> Having the user click again to keep listening after 5 hours is perfectly > >> reasonable. > > > >This is a reasonable root cause of the problem, without passing judgment on > >whether this is "perfectly reasonable" for an ISP. > > If someone has flat rate water service and leaves the tap on 24x7, it's > reasonable to cut him or her off or start billing by the gallon. This > situation is analogous. > > >It would be very easy to check to see what the lease on the DHCP IP address > >is for Ron. And, it is VERY unlikely that he would get a week or two lease, > >and then all of a sudden get leases that only last for an hour for a period > >of time, only to be followed by another period of week or so long leases. > > The leases may be short, but the IP address may not change every time. I've > seen this on many dynamic cable modem connections. > > --Brett Glass >