Re: why strict Net neutrality works best: simple beats complex

Think of flying; and then sky is the limit (pun intended).
And now what do the road and train barons do?
that is the 64k$ problems of Telco who own the data pipes today.
The will always remain the last mile and here 5G promises to make FTTC/FTTH
obsolete just as ADSL is facing 3-4G challenge.

I use the road/train analogy because politicians understand that better
than the inner workings of IPv6, throttling traffic, etc.
The underlying issue is the same: who pays for the roads/trains/ planes
cause these do not come free and so strict net nuetrality can not sustain
the investments required.

The issue then is what business models are allowed (hence regulations)?

We need to start thinking now so that they are in place by the year
2020-2025!

IMHO the technology will advance so fast that the solution can not be
technology specific (eg do not look at how routers work or limit header
field analyses). So we do need to provide a solution which does allow
priority based on known regulated criteria

BR
Kirit
On May 19, 2015 1:07 PM, "Vickram Crishna" <v1clist-/[email protected]> wrote:

> The roads analogy naturally only takes one so far. Synchronising
> technologies, in the meantime, have leaped forward, which means that it is
> far more feasible today to optimise data travel lengths, within a few,
> geographically sensible, hops. Of course that requires some far sighted
> rethinking on what constitutes IPR. Still, the robot surgeon need not
> compete with Fast and Furious 9.73's robot actors for packet priorities.
>
> And ideas like this also come up against the steaming pile that is telco
> thinking on billing and accounting. Very narrow viewpoint.
>
> Sent from Yahoo Mail on Android
> <https://overview.mail.yahoo.com/mobile/?.src=Android>
> ------------------------------
>   *From*:"Kiritkumar Lathia" <[email protected]>
> *Date*:Tue, 19 May, 2015 at 4:27 pm
> *Subject*:Re: [india-gii] why strict Net neutrality works best: simple
> beats complex
>
> Hello Arun,
>
> I am interested in the ITU presentation you made in Pune!
>
> I am also one of the old veterans having started my telecom experience
> with CCITT #6 Signalling System (SS#6) - before the ITU name! I believe it
> was the first time packet switching was used!
>
> I think we need to recognise what happened: ITU did X.25, X.75, etc. as
> "telecom rugged" with belt/braces/... and so were very complicated and
> failed in market place since it was over engineered but more to the point
> it was going to canabalise the cash cow (Switching Systems) since the major
> part of the revenue stream was in voice telephony.
>
> Internet (TCP/IP) started with DARPA (and later ARPA) as a rudimentary
> communication system which would survive a nuclear attack which takes out
> key telecom nodes. (Remember, circuit switched telecom is still highly
> pyramidal and taking out the APEX would rend the whole network useless.)
>
> Hence TCP/IP did not have telecom needs for charging, metering, etc. but
> the need to have the "self-healing" features in case a node was taken out.
> Hence each packet needs to be examined (for routing) and the edge performs
> packet assembly/dis-assembly. The common technique for priority (traffic
> class field) is to create "virtual circuit switch" (by suitably using the
> flow/QoS field) so that the packets use the same paths and lower the
> re-assembly time at the edge. Better techniques are coming or being
> utilised with IPv6 but not all Internet is at IPv6 level!
>
> Arun, whether one wants to or not, these all packet header fields need to
> be analysed to allow proper packet flow. The Priority/Traffic Class is a 8
> bit field if I remember correctly so you are not going to have that much
> choices in the priorities. That is why I try to always explain by using
> roads as example. During Commonwealth games, a priority lane was
> "permanently" created for VIPs traffic - think of this as a dedicated
> "virtual circuit switch". On the other hand you have ambulances, police,
> etc. who want to have priority on the road so they can save lives. One know
> this by flashing lights and sirens - consider this as "Priority Class=x".
> People have to move out (throttled) to allow the priority cars to go
> forward.
>
> This will be needed more and more as we move to 5G which will change the
> Internet we know it today with a conservative estimate of 50+billion
> devices connected to Internet vs about 6billion for human beings! When we
> talk about e-health where a surgeon is operating on a patient remotely
> using robotic arms and instruments; should this suffer the same potential
> delays because someone is downloading a film?
>
> So "net neutrality" is much more nuanced and the packet header analysis
> will be a must. So there will be (almost) no time saving if one were not to
> analyse the Traffic Class filed in IPv6 to provide "net neutrality". What
> is needed is good "regulation" (!) to provide "net neutrality"; hence in
> USA FCC is now charged with coming up with USA regulations to provide "net
> neutrality". Note also that the big players (Goggle, ...) are busy building
> their own roads to bypass the existing roads!
>
> Up to now the discussions were "muted" because most of the Internet
> traffic was using "spare" capacity of telcos and the Internet traffic
> provided additional revenue on the big roads that were built (and
> maintained). Their cash cow was normal telephony. This is fast disappearing
> with OTT so they are in a bind - why should they invest in more roads and
> maintain them if there is no return-on-investments?
>
> Curiously, even for Internet, the only existing models for payments of
> traffic is still the good old "settlement of accounts" of ITU / SG3 and
> "bulk buying".
>
> Governments are not going to build and maintain all the roads so if you
> involve "fast toll roads", one does pay a toll and get from point A to
> point B fast - correct? The issue is to what level these toll roads control
> traffic? (Think of Bangalore airport - one has to pay the toll as there is
> no alternative!)
>
> And then you have a different business model of "free" Internet from the
> Facebook initiative Internet.Org!
>
> To conclude: I think the solution of "net neutrality" is not in the
> Internet routers not analysing the header information but in Governance on
> how "public" roads are used as opposed to totally private roads where the
> only traffic is that of the road owner.
>
> Best wishes,
> Kirit
>
>
>
> On 19 May 2015 at 05:34, Abhijit Gadgil <[email protected]> wrote:
>
>> Very well said - I am myself a big fan of Ethernet, if you throw
>> enough money behind a technology, it's not very hard to make it do
>> what you want, even if it wasn't ever meant to do that (Internet being
>> a case in point). While most of your arguments about simplicity, I
>> completely agree with - I do not agree with
>>
>> > Any violation of net neutrality adds to complexity. Once you let the
>> > marketing guys call the shots, the complexity only grows. Any change you
>> > implement involves changing the software, which becomes bloated and
>> buggy.
>>
>> All of us would agree that any use of shared resource needs some
>> policing - if for nothing else - to at-least prevent it from being
>> hogged completely by rogue elements to the extent it becoming
>> unusable. So whether we like it or not - wherever humans (or programs
>> written by humans) are involved - policing is required. Fortunately
>> (or unfortunately) the same tools or techniques that can be used to
>> police rogue traffic can also be used to 'prefer a traffic you want to
>> serve better', so 'that doesn't come at any (significant) additional
>> cost. Most of these techniques are already implemented even in Linux -
>> so someone with a thousand dollar budget can do it at 1gbps speed and
>> with some creativity - _nearly_ @ 10gbps speeds on a workstation grade
>> machine.
>>
>> > This is why I believe that strict net neutrality will win.
>>
>> I am not sure whether it will  or it won't and frankly I don't care.
>> Here's why - Internet (or more specifically TCP/IP protocol stack)
>> succeeded because it was open to experiment and failures (and started
>> offering non-critical path solutions and moved up the value chain).
>> The ITU technology stack suffered the most because it was very hard to
>> contribute to standards (and hence participate in experiments) and
>> when a critical point was hit by Moore's law the game entirely
>> shifted.
>>
>> Let's all accept that the Internet today is not the same research
>> network that connected universities, but a commercial network where
>> corporations would try to squeeze value out of it. That's a reality
>> we've to live with. Whoever that corporation is - doesn't matter. What
>> I still strongly believe in - if thanks to many Telco's and OTT
>> players' efforts Internet becomes a network hard to experiment with -
>> without deep enough pockets and eventually ends up becoming what
>> Telecom networks were a few decades ago, there'd be another networking
>> paradigm - that will win and so on. Hence I am not concerned whether
>> net neutrality would win.
>>
>> However, as a Telco, it will be economically 'stupid' to _not_ follow
>> net neutrality - at least broadly (so I am okay if a Telco punishes
>> bi-torrent traffic - even severely - a very personal opinion) and if
>> the Telcos do that markets (not just capital markets) would punish
>> them, but in principle I would still support their decision to do so.
>>
>> So to conclude - I'd say - an economical solution would eventually win
>> - and what that is we don't know. It's very easy to explain things
>> post facto and very very hard to predict what's likely to happen!
>>
>> -abhijit
>>
>> PS: I work for a company whose products and services might _look_like_
>> violating net neutrality. I believe, a disclaimer to this effect is
>> certainly required in this case.
>>
>> _______________________________________________
>> India-gii mailing list
>> India-gii-IAPFreCvJWP2/[email protected]
>> https://lists.india-gii.org/mailman/listinfo/india-gii
>>
>
>
> _______________________________________________
> India-gii mailing list
> India-gii-IAPFreCvJWP2/[email protected]
> https://lists.india-gii.org/mailman/listinfo/india-gii
>
>

_______________________________________________
India-gii mailing list
India-gii-IAPFreCvJWP2/[email protected]
https://lists.india-gii.org/mailman/listinfo/india-gii