[ NNSquad ] Re: ISP's resetting RealPlayer?

["Fred Reimer" <freimer@ctiusa.com>]

Wrong on so many levels, but not all.

Fred Reimer, CISSP, CCNP, CQS-VPN, CQS-ISS
Senior Network Engineer
Coleman Technologies, Inc.
  

> -----Original Message-----
> From: nnsquad-bounces+freimer=ctiusa.com@nnsquad.org [mailto:nnsquad-
> bounces+freimer=ctiusa.com@nnsquad.org] On Behalf Of Brett Glass
> Sent: Friday, January 11, 2008 3:52 PM
> To: Ron@usmedrec.com; nnsquad@nnsquad.org
> Subject: [ NNSquad ] Re: ISP's resetting RealPlayer?
> 
> At 11:23 AM 1/11/2008, Ron Teitelbaum wrote:
> 
> >Does anyone else have this issue, or has anyone looked whether or not
> ISP's
> >might be limiting content by sending resets to clients that are not P2P?
> 
> The most likely cause is that your streaming provider, which has limits on
> the number of streams it can sustain, is timing you out after you've been
> on a long time. Sometimes a streaming audio server will break an "old"
> connection to only if all of the available streams are full when it gets a
> new request. That's only fair; you've listened for awhile and it's now
> someone else's turn.

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.  True, they may have a variable
amount of time after which they drop connections, but it would not very as
much as Ron said it does.  And I find it hard to believe that the servers
would reach their maximum number of connections on such a regular basis.  If
they did, they would not all of a sudden start resetting a single user's
connection "every hour or so."  This explanation is possible, but in my
opinion very unlikely.

> 
> 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.
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.
If the "tables are filling up" then that only points to incompetence on the
part of the ISP, or whoever is running the theoretical stateful firewall.
It is very unlikely that any end-user firewall, in a "consumer" cable modem
context, would ever run out of room it the state table.

> 
> 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.

> 
> Frequently, when I stay in hotels or visit hotspots (e.g. at coffeehouses
> or airports), I need to re-establish my VPN or SSH sessions every hour or
> so, presumably for this reason. It's not a big deal; just one click and
> I'm back online.
> 
> Your interrupted streams may also stem from another cause. If you do not
> have a static IP address, you may find that long term connections are
> interrupted when your IP address is renewed or changed. In this case, it's
> not the result of a policy decision by the ISP at all, but just a normal
> and natural side effect -- and you can avoid it by paying for a static IP
> address.

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.  I
don't think this is a very good explanation of the behavior at all.

> 
> --Brett Glass, LARIAT.NET
> 
>

Attachment: smime.p7s
Description: S/MIME cryptographic signature