[Chapter-delegates] net neutrality vs DNS redirection
Franck Martin
franck at sopac.org
Mon Jul 21 19:30:19 PDT 2008
For anti-spam measure, in postfix, sendmail, spamassassin, it is a
common test to check if sender domain exists and has an MX record.
There is a new way of thinking, that in fact placing a P2P node at an
ISP saves a lot of bandwidth. It is becoming like P2P is helping
localise traffic.
More and more, applications, patches, software updates are distributed
via bit-torrent. Having a local bit torrent node managed by the ISP
will save him a lot of non-local traffic.
Finally, I have heard about QOS for years... It simply does not work,
because the money you spend in setting up QOS, you can spend the money
in increasing the bandwidth and have the problem solved as well.
Anyhow, I'm not against ISPs prioritizing traffic, but they should be
"extremely clear" on what they are doing.
Franck Martin
ICT Specialist
franck at sopac.org
SOPAC, Fiji
GPG Key fingerprint = 44A4 8AE4 392A 3B92 FDF9 D9C6 BE79 9E60 81D9 1320
"Toute connaissance est une reponse a une question" G.Bachelard
Narelle Clark wrote:
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://elists.isoc.org/mailman/private/chapter-delegates/attachments/20080722/a8a75940/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
URL: <https://elists.isoc.org/mailman/private/chapter-delegates/attachments/20080722/a8a75940/attachment.asc>
More information about the Chapter-delegates
mailing list