[Chapter-delegates] net neutrality vs DNS redirection

[Alejandro Pisanty]

Dear Narelle,

I'm glad that you are starting to separate these issues into different 
classes.

DNS redirection is IMO far from traffic shaping and both issues should be 
discussed separately, as you have now very properly started.

Yours,

Alejandro Pisanty


.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  . .  .  .  .  .  .
      Dr. Alejandro Pisanty
UNAM, Av. Universidad 3000, 04510 Mexico DF Mexico

Tels. +52-(1)-55-5105-6044, +52-(1)-55-5418-3732

*Mi blog/My blog: http://pisanty.blogspot.com
*LinkedIn profile: http://www.linkedin.com/in/pisanty
*Unete al grupo UNAM en LinkedIn, http://www.linkedin.com/e/gis/22285/4A106C0C8614

---->> Unete a ISOC Mexico, http://www.isoc.org
  Participa en ICANN, http://www.icann.org
.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .


On Tue, 22 Jul 2008, Narelle Clark wrote:

> Date: Tue, 22 Jul 2008 12:20:36 +1000
> From: Narelle Clark <Narelle.Clark at optus.com.au>
> To: 'Franck Martin' <franck at sopac.org>
> Cc: "'chapter-delegates at lists.isoc.org'" <chapter-delegates at elists.isoc.org>
> Subject: Re: [Chapter-delegates] net neutrality vs DNS redirection
> 
>
>> From: Franck Martin [mailto:franck at sopac.org]
>> Sent: Tuesday, 22 July 2008 11:09 AM
>>
>> Many applications work on the presumption that some domains
>> do not exist. Take anti-spam measure, if you receive an
>> e-mail and your software checks the domain and find
>> something, then it may consider it is all good.
>
> Excellent example. I'd love to check out some examples. Please send them to me off list.
>
> Can this be effectively built into antispam measures in DNS, or is it better to be in the SMTP ones? Should these standards be modified to guarantee this sort of effective anti-spam behaviour remains effective?
>
>> There is no problem for the  web browser, to suggest you
>> alternatives (you installed the web browser and configured it
>> the way you like), but for the network operator to have a
>> deep look in your traffic and start to modify it, this is
>> what we are against. Next step is to intercept ads, and
>> replace them with the ISP own ads (there are some software
>> that already do that, see Scott Bradner column). Then the ISP
>> can for instance insert ads in your chat messages, emails, etc...
>>
>> So we need to make a stand now.
>
> Here, I have to agree and disagree.  Agreed: content replacement, even with consumer consent, is fraught with issues, and very often arguably inappropriate. Advertising replacement could also be anti free trade principles, ie anti-competitive and an unacceptable barrier to entry.
>
> Don't stop at advertising: I certainly don't want to see a world where people can live completely in an information bubble never seeing alternatives to proscribed doctrine!
>
> These cases can well be classified as against the basic principle of a _Public_ Internet.
>
> We most certainly should take a stand.
>
>
> BUT - If network operators cannot balance traffic, then bandwidth hungry applications designed by software developers, with little regard to the operation of networks, will dictate traffic delivery. Individual Internet users wanting to look up the bus timetable, or ring their mothers via voip, or check their medical or banking services, will have to wait while their next door neighbour downloads a film and another film, and the whole season of Dross. [Films even full to the brim of unconsented product placement.]
>
> Given the vast majority of bandwidth hungry applications exploit loopholes in tcp and fail to declare that they are ftp-like applications masquerading as http then network operators have no other choice but to look deep into traffic in order to give a fairer throughput to that traffic.
>
> Who do you actually want to determine how traffic flows in and out of your house - network engineers that you commission for a service, or your next door neighbour's anonymous application software developer?
>
> Very, very few application software developers use TRUTHFUL TCP or UDP port descriptors any more. These were the traditional ways network operators could buffer and prioritise traffic across the networks. Now it is virtually impossible without deep packet inspection (DPI). Hence a small number of people's P2P file sharing dominates over the myriad of other applications used by the many.
>
> Come on, let's face it, P2P file sharing is NOT bandwidth friendly. Unprioritised VoIP + P2P file sharing is almost completely incompatible.
>
> Application software developers care only whether their software works (often only at the time of testing!), hence their motivation is not necessarily to make it co-exist well with any other application!
>
>
> And we haven't even started to talk about transcoding for small device screens, disability services etc etc. That's another area of arguably legitimate traffic modification that this line of argument declares out of bounds, unacceptable etc etc.
>
> Nor have we talked about DPI for virus prevention, spam redirection, dos mitigation etc.
>
>
> I suggest that this needs to have a more reasoned and principle driven discussion, and that DNS, QoS, consumer rights etc all need to be brought into it and guaranteed, rather than swept out of hand by emotive arguments against advertising. By doing the latter you well and truly throw the baby out with the bathwater.
>
>
> Best regards
>
>
> Narelle
> ISOC-AU
>
> _______________________________________________
> Chapter-delegates mailing list
> Chapter-delegates at elists.isoc.org
> http://elists.isoc.org/mailman/listinfo/chapter-delegates
>