[LINK] ACS new? submission on ISP filtering

[Roger Clarke]

>On 19/03/2010, at 11:38 AM, Roger Clarke wrote:
>>  I suspect that "triples the latency" is a serious
>>  over-estimate.  No, I don't have a simulator handy to experiment
>>  with, but presumably someone has).

At 12:29 +1100 19/3/10, Stilgherrian wrote:
>Don't need an experiment, Roger, it's east to demonstrate. And I'm 
>about to prove myself wrong by showing it's only double, not triple 
>the latency.
>
>For any content not hosted in the next room, the major cause of 
>latency would be the travel time for the packets from client to 
>server and back.
>
>Asking for content with HTTP: Trip 1 HTTP GET request sent. Trip 2 
>Data returned.
>
>Checking with HTTP HEAD first: Trip 1 HTTP HEAD request sent. Trip 2 
>Data returned. Trip 3 HTTP GET sent. Trip 4 Data returned.
>
>Close enough?

I don't think so (*but* I'm an amateur, and haven't looked at any of 
this stuff in any depth for years):

(1)  TCP-opening involves a bunch of packets before the data is sent
      (and afterwards, depending).  The apparent latency at the user's
      device is a function of the complete session traffic rather than
      just the content-flows.  (And the overheads are substantial)

(2)  A large file will involve scores or hundreds of packets travelling
      across the backbone, when they could have been fetched more
      locally.  I accept that I'm assuming that fetches from
      network-distant sources will be slower than from network-close
      nodes

Hence my preference for someone to offer me a gratis simulator  (:-)}


>Either way, the lag between requesting content an it starting to 
>appear on screen is the biggest factor in users deciding to skip off 
>the site. I don't see slowing this process down being much of an 
>advantage.

The rational (profit-maximising) ISP couldn't give a toss whether 
their customers find some sites a pain.  In fact, ISPs would probably 
prefer to (accidentally, of course) discourage their customers from 
visiting sites that are painful to the ISP.


>Then again, why are we even discussing this? Isn't worrying about 
>this what we have network engineer minions for?

<straight face>

Whether (and if so then how) intermediating devices perform actions 
on traffic rather than just passing it on, is a vital policy matter.

A while back, I nattered on about deep packet inspection here:
http://www.rogerclarke.com/II/DPI08.html

</straight face>

Nice trick to try to get Glen back on the case, and others involved  (:-)}


-- 
Roger Clarke                                 http://www.rogerclarke.com/

Xamax Consultancy Pty Ltd      78 Sidaway St, Chapman ACT 2611 AUSTRALIA
                    Tel: +61 2 6288 1472, and 6288 6916
mailto:Roger.Clarke at xamax.com.au                http://www.xamax.com.au/

Visiting Professor in the Cyberspace Law & Policy Centre      Uni of NSW
Visiting Professor in Computer Science    Australian National University