NNSquad - Network Neutrality Squad
[ NNSquad ] Re: ISP's resetting RealPlayer?
At 05:48 PM 1/11/2008, Fred Reimer wrote:
>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