Subject: [conex] An interesting video

From: Matt Mathis <[email-masked]>
Date: Wed, 19 Dec 2012 08:08:30 -0800

An interesting video, relevant to this group:  "Jonas Eliasson: How to
solve traffic jams" http://youtu.be/CX_Krxq5eUI [TED Talks]

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

Privacy matters!  We know from recent events that people are using our
services to speak in defiance of unjust governments.   We treat
privacy and security as matters of life and death, because for some
users, they are.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 19 Dec 2012 18:03:38 +0100 (CET)

> solve traffic jams" http://youtu.be/CX_Krxq5eUI [TED Talks]

I have some input. The system he's talking about (Stockholm congestion 
charging system) costs around 100MUSD per year to operate. How much roads 
could we get for the same amount of money, and would that be a better 
investment? The answer seems to have been "no". (I live in Stockholm, I'm 
one of the people he's referring to who disliked the system initially and 
who now likes it).

So let's take the analogy to this group. How much would it cost to bring 
in an infrastructure to create the incentives to make people adapt to move 
some of their traffic to another part of the day, or not run the traffic 
at all (which is what a traffic congestion system tries to achieve).

I don't believe I have seen a system that actually reduces cost by trying 
to intelligently manage congestion or moving traffic spatially, compared 
to the cost of building out the network. A lot of the success of the 
Internet has been flat-rate billing so one basically doesn't have to have 
a lot of system and staff to handle usage-based billing. I don't really 
see how a congestion management system would fare any better. It adds 
complexity to the Network and I don't see how it would really help. 
Basically I don't see the incentives for the user to change.

But I'd gladly be proven wrong, that's why I follow this mailing list.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: John Leslie <[email-masked]>
Date: Wed, 19 Dec 2012 12:20:08 -0500

> solve traffic jams" http://youtu.be/CX_Krxq5eUI [TED Talks]

   Indeed!

   ~ 1-euro tolls at congestion points reduced traffic 20% and totally
solved the congestion.

   But the amazing part is, nobody noticed they had changed anything;
and most amazing of all, roughly half of those who initially opposed
the tolls came to believe they had liked them all along!

   ;^)

   I've believed all along that ConEx can operate on a sender-pays model
with "settlements" where essentially nobody will notice having changed
anything and everybody will believe they've always been in favor...

   (Not that we are in any way charged to design a settlement system.)

   The point I _would_ like to make is that I believe "cheaters" will
be found out naturally in any real-world "settlement" system without us
needing to prescribe a particular method in the protocol.

   (It's probably good to _describe_ _a_ method; but entirely different
methods are likely to be the ones actually used.)

   And... I recommend the video!

--
John Leslie <[email-masked]>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 19 Dec 2012 18:28:08 +0100 (CET)

>   ~ 1-euro tolls at congestion points reduced traffic 20% and totally

2 EUR per passing, and no, it didn't solve the congestion, it made it less 
(I guess it would have been a worse talk if he actually would have 
presented real figures).

What he also doesn't talk about is that after that 20% decrease in 
traffic, traffic still increased yearly at the same rate so now we have 
multi-hour congestion again (basically they bought 5-8 years to implement 
a real solution, and then did nothing).

But I'm digressing, I'm still interested in how this could be done on the 
Internet in a cost-effective way (both OPEX and CAPEX).

---

From: Dirk Kutscher <[email-masked]>
Date: Wed, 19 Dec 2012 18:01:40 +0000

Hi,

The video is alright, but the analogy is a bit limited, in my view.

Car traffic jams are mostly cases of pathological congestion, i.e., congestion makes the systems (close to) unusable. In the Internet, we have transport protocols to prevent this.

What transport protocols today do not enable without network infrastructure support is capacity sharing that ensures good performance for different application types and users in the presence of full network utilization. For example, keeping latency low for my short-lived AJAX interaction although it has to share bottlenecks with other users's bulk data transfers.

In a street network, you want the trucks to yield for the much faster ambulance, so that the ambulance passengers get acceptable quality of experience and so that the truck drivers can still use all lanes under normal conditions. (I am bad at analogies. ;-)

A complete metering and charging infrastructure is indeed non-trivial and expensive to operate.  ConEx is essentially intended as not too complex (i.e., cost-efficient) network infrastructure support to incentivize such sharing. And that does not imply a general toll collect for all traffic as in the video.

Best regards,
Dirk

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Mikael Abrahamsson
> Sent: Mittwoch, 19. Dezember 2012 18:04
> To: Matt Mathis
> Cc: ConEx IETF list
> Subject: Re: [conex] An interesting video
> 
> charging system) costs around 100MUSD per year to operate. How much
> roads could we get for the same amount of money, and would that be a
> better investment? The answer seems to have been "no". (I live in
> Stockholm, I'm one of the people he's referring to who disliked the system
> initially and who now likes it).
> 
> So let's take the analogy to this group. How much would it cost to bring in an
> infrastructure to create the incentives to make people adapt to move some
> of their traffic to another part of the day, or not run the traffic at all (which is
> what a traffic congestion system tries to achieve).
> 
> I don't believe I have seen a system that actually reduces cost by trying to
> intelligently manage congestion or moving traffic spatially, compared to the
> cost of building out the network. A lot of the success of the Internet has
> been flat-rate billing so one basically doesn't have to have a lot of system and
> staff to handle usage-based billing. I don't really see how a congestion
> management system would fare any better. It adds complexity to the
> Network and I don't see how it would really help.
> _______________________________________________
> conex mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/conex

---

From: John Leslie <[email-masked]>
Date: Wed, 19 Dec 2012 13:06:44 -0500

> at all (which is what a traffic congestion system tries to achieve).

   Umm... those aren't the only two possibilities, actually...

> to the cost of building out the network.

   There are already _many_ multiple paths from sender to receiver: we
don't have to build-out for these to exist. Our routing system, however,
ignores them because it's optimized for something else.

   Rather than change the routing system (IMHO), it's more likely we'd
build an overlay upon it able to "avoid" congestion by not following the
"direct" path. With a system of settlements, ISPs would have a reason to
_use_ the overlay system for some portion of traffic not marked for
"priority". The "cost" of doing so would be tiny.

> A lot of the success of the Internet has been flat-rate billing so one
> basically doesn't have to have a lot of system and staff to handle
> usage-based billing.

   Correct! A lot of plain-old-telephone-service companies are suffering
big-time from trying to maintain their usage-based billing systems. We
don't expect to charge individual end-users here.

> I don't really see how a congestion management system would fare any
> better. It adds complexity to the Network and I don't see how it would
> really help. Basically I don't see the incentives for the user to change.

   I'm not sure my views are considered "mainstream" anymore, but at first
our drafts were written in terms of a "congestion allowance" to the user
where the user would see no change in price, merely a limit on how much
of his/her traffic would be marked for priority at congestion points.
(The ISPs would resolve any imbalance with settlements, or merely drop
some congestion-expected traffic in the absence of settlement agreements).

   Toby and I being told to shut up, we have mostly done so; and now the
drafts concentrate on how to catch cheaters, without even discussion of
_why_ anybody could be bothered to cheat.

> But I'd gladly be proven wrong, that's why I follow this mailing list.

   :^)

   It's certainly possible that some actual protocol will come out of
this WG yet...

---

From: David Wagner <[email-masked]>
Date: Fri, 21 Dec 2012 13:00:16 +0100

> a real solution, and then did nothing).

I regard the expectation of such incentive-attenuating effects being an important issue for ConEx, too. Such concerns might even hinder a deployment of ConEx. 
So one of our goals should be to show that the application of ConEx can maintain comparability between network services and thus competition and incentives to continously extend & grow. 

Of course, ConEx may be a tool to motivate people to distribute their load smoother which will result in lesser pressure on networks and shifted upgrades. At first. In that way I expect a somehow similar effect as of Stockholm's traffic fee. But after this phase, incentives to satisfy growing client demands should reconstitute themselves. 

David

-- 
Dipl.-Inf. David Wagner
Institute of Communication Networks and Computer Engineering (IKR)
University of Stuttgart
Pfaffenwaldring 47, D-70569 Stuttgart, Germany

web: www.ikr.uni-stuttgart.de   email: [email-masked]
phone: +49 711 685-67965        fax: +49 711 685-57965
-------------------------------------------------------------------