Subject: Re: [its] Article + TED talk

From: Alison Chaiken <[email-masked]>
Date: Thu, 1 Aug 2013 00:11:21 -0700

Emmanuel Baccelli <[email-masked]>
> But realistically, nowadays, you rather have to justify why you're *not*
using IP, rather than why you *are* using IP.

Automotive intranets by and large do not use IP.      It's not yet clear
within cars whether the newer EthernetAVB will use IP or not.    EAVB is
displacing the expensive FlexRay (essentially a TDMA variant of Controller
Area Network) and CAN (collision-detection with bus priority arbitration).
  Within GENIVI automotive consortium (about 170 car companies and
suppliers), the arguments against IPV6 for "internode communication" are
also about the size of data payloads versus header overhead similar to Dick
Roy's

Those 37 saved bytes turn out to be roughly somewhere from 5-10% (depending
on data sent, certificate sizes and a few other things) of the transmitted
stream (PPDU) over the air, and that's not inconsequential when talking
about your personal physical safety or that of your family!

> I don't think 5-10% savings are a good enough reason to not use IP.

Perhaps using a protocol other than IP will also have security benefits?
The PKE model of DSRC, with its reserved safety channel and reserved PSIDs,
seems pretty appealing for safety applications.

>  if using IP makes the technology cheaper (which often happens nowadays),

I have spoken about 802.11p and DSRC to a Qualcomm employee who formerly
worked for Atheros.   He is working on a BSD-licensed 802.11p driver and
says that the amount of changes needed to existing 802.11 drivers are not
extensive or challenging to implement.     Meanwhile, Marcel Holtmann of
Intel, chief author of Ofono and Connman, tells me that they should "just
work" with DSRC.   So the experts seem to think that from the software
point of view, the lower-level driver work should be straightforward.
Implementing IEEE-1609 is, of course, another matter.

Regarding congestion on wireless channels in heavy  vehicle traffic,
consider the case of dense fog or a multi-car accident ahead.    An
approaching vehicle could be warned by any single stopped or slow car: it
doesn't need to receive messages from all of them!

Regarding pedestrians and cyclists mentioned by Dick Roy, why not have the
safety system flash the headlights or honk the horn instead of using the
driver as an intermediary to do so?    I was quite struck by this video
sent recently by a fellow cyclist:

http://youtu.be/k7oGk-ozhKI

Sometimes simple audio warnings are the best modality to reach people.
 Why vibrate an endangered pedestrian's cell phone when you can just beep
loudly?

I hope the Bar BoF goes well,
Alison

-- 
Alison Chaiken                           [email-masked]
650-279-5600                            http://{she-devel.com,
exerciseforthereader.org}
The intermediary between the head and the hands must be the heart.    --
Thea von Harbou

---

From: Rex Buddenberg <[email-masked]>
Date: Thu, 01 Aug 2013 07:04:14 -0700

On Thu, 2013-08-01 at 00:11 -0700, Alison Chaiken wrote:
> > But realistically, nowadays, you rather have to justify why you're
> *not* using IP, rather than why you *are* using IP.
> 
> Automotive intranets by and large do not use IP.      It's not yet
> clear within cars whether the newer EthernetAVB will use IP or not.
>  EAVB is displacing the expensive FlexRay (essentially a TDMA variant
> of Controller Area Network) and CAN (collision-detection with bus
> priority arbitration).   Within GENIVI automotive consortium (about
> 170 car companies and suppliers), the arguments against IPV6 for
> "internode communication" are also about the size of data payloads
> versus header overhead similar to Dick Roy's
> 
>         Those 37 saved bytes turn out to be roughly somewhere from
>         5-10% (depending on data sent, certificate sizes and a few
>         other things) of the transmitted stream (PPDU) over the air,
>         and that's not inconsequential when talking about your
>         personal physical safety or that of your family! 
> 

The discussion seems to have missed:

> For these single-hop unacknowledged broadcast use cases, which are
> driving deployment of DSRC/C-ITS, IP offers no advantage
> 
John Kenney has the caveats exactly right: no ACK, single hop.  

If those caveats are not valid -- for example, you have an app that
requires multiple hops to get data from A to B, then you'll probably
want to run it over IP rather than some reinvention of IP.  

For a wholly in-car comms app, the single-hop caveat holds.  But it gets
shaky when we have any radio aspects involved because you have LAN in
vehicle plus the radio net.  If you keep the single-hop mentality, then
you will have a rather app-specific structure.  

> Perhaps using a protocol other than IP will also have security
> benefits?   The PKE model of DSRC, with its reserved safety channel
> and reserved PSIDs, seems pretty appealing for safety applications.

This is the discussion that needs to be held.  If the non-IP route is
pursued, will the security model be 'obscurity'?  All our experience in
the internet tells us that that only works short term.  

If we take the 'real authenticity' approach (which I think we're going
to need to) then the signatures will eat up all the savings you shaved
in the protocol chiseling.  ... and more.

My experience watching things hybrids like this over the years ... my
initial reaction is same as Emmanual's: why are you reinventing
something other than IP?  And the answer is usually ignorance (yeah,
John says otherwise).  But if IP can coexist on the plumbing, then
there's no reason to get blood pressure up.  

Example: 15 years ago, there was a push by the housing industry to
create household LANs.  Using existing CATV cabling and existing power
wiring (power line carriers seem to be technology that reappears on
about 7 year cycles).  The push never got any traction because 1) it was
not all that difficult to wire your house for ethernet and 2) WiFi
eclipsed this deviant behavior.  

> I have spoken about 802.11p and DSRC to a Qualcomm employee who
> formerly worked for Atheros.   He is working on a BSD-licensed 802.11p
> driver and says that the amount of changes needed to existing 802.11
> drivers are not extensive or challenging to implement.

Ethernet framing is very simple: payload with a header/trailer
surrounding it.  None of the header knows or cares what's in the payload
except the ethertype.  So there's no problem with a non-IP protocol
(batch of ethernet frames) coexisting with IP protocol.  (Are we not old
enough to remember Appletalk?)

>      Meanwhile, Marcel Holtmann of Intel, chief author of Ofono and
> Connman, tells me that they should "just work" with DSRC.   So the
> experts seem to think that from the software point of view, the
> lower-level driver work should be straightforward.   Implementing
> IEEE-1609 is, of course, another matter.
> 
> 
> approaching vehicle could be warned by any single stopped or slow car:
> it doesn't need to receive messages from all of them!
> 
> 
> Regarding pedestrians and cyclists mentioned by Dick Roy, why not have
> the safety system flash the headlights or honk the horn instead of
> using the driver as an intermediary to do so?    I was quite struck by
> this video sent recently by a fellow cyclist:
> 
> 
> Sometimes simple audio warnings are the best modality to reach
> people.    Why vibrate an endangered pedestrian's cell phone when you
> can just beep loudly?
> 
> 
> The intermediary between the head and the hands must be the heart.
>  -- Thea von Harbou
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its

---

From: Alison Chaiken <[email-masked]>
Date: Thu, 1 Aug 2013 09:04:37 -0700

>> driving deployment of DSRC/C-ITS, IP offers no advantage

No, we are in complete agreement there, although Emmanuel's points
about popularity and cost of IP are worth considering.    New
standards must overcome a barrier to acceptance just because they're
new and must be implemented and tested.

I wrote:
> pursued, will the security model be 'obscurity'?

DSRC is a published standard, not "security by obscurity," about which
we share a low opinion.

> IP can coexist on the plumbing, then there's no reason to get blood pressure up.

Concur: for safety applications, there seems to be little motivation
to use IP, but for other applications like location-based services,
traffic management, etc., there may be compelling reasons.

> eclipsed this deviant behavior.

In just such a fashion, LTE is likely to eclipse 802.11p, whether we
like it or not.     I'm thinking about how to propose a DSRC/CALM
activity within GENIVI, as we need to get cracking if we don't want to
wake up and find out that DSRC is dead.     The U.S. FCC's
consideration of allowing other uses for the 5.9 GHz spectrum may be a
death blow already.   Last I heard, FCC would announce its decision at
end of 2013.   At least the NHTSA Safety Pilot trial should have
reported results by then since I'm sure the American government must
run its own test and not rely on simTD!

---

From: Rex Buddenberg <[email-masked]>
Date: Thu, 01 Aug 2013 09:23:52 -0700

On Thu, 2013-08-01 at 09:04 -0700, Alison Chaiken wrote:
> DSRC is dead.     The U.S. FCC's
> death blow already.  

This is a conundrum that the FCC has been wrestling with for a long
time.

Historically, spectrum allocations have been to specific applications.
Which is what DSRC seems to be.  Like chunks of VHF spectrum to
television, other chunks to maritime voice, etc.  The consistent thread
is one-to-one pairing of app and spectrum.  

But the internet is infrastructure that supports 1001 applications.  So
allocation of spectrum to internet use thoroughly breaks the
app-spectrum model.  Indeed, the old model isn't just old, it's
counterproductive in most (comms*) cases.  The worst case of this
breakage does indeed intrude on the [its] discussion: Congress set aside
(somewhat pre-empting what should be FCC's prerogative) a chunk of
spectrum in 700MHz range for emergency services.  EMS uses vehicles --
fire engines, police cruisers, ambulances, ... so we clearly have an
intersect.  But if you're not EMS, then you're not supposed to be in
this chunk of spectrum.  This presents a major and minor problem plus
poor economy:
  - poor economy -- EMS has to have two comms systems, one for
themselves and one to communicate with the public that they exist to
serve.
  - minor.  Just who is EMS?  Does it include the Wyoming snowplow that
I've used before?  
  - major.  The spectrum-segregation problem inhibits
interoperability.  

*the one-one pairing still makes sense for radionav apps like GPS and
Loran.  And it still makes sense for sensory apps like radar.

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Thu, 1 Aug 2013 20:13:48 -0500

> counterproductive in most (comms*) cases.

This is one of the big pushes for Dynamic Spectrum Access (DSA).  It is not
just for the military.  Rather, it could be argued to be much more cost
effective for commercial applications.  Basically, dynamic spectrum sharing
to determine locally unused spectrum, and then operate on these channels
without causing interference to the existing users.

-- Will

---

From: Rex Buddenberg <[email-masked]>
Date: Thu, 01 Aug 2013 18:38:51 -0700

Will,

Flip over to the PAWS working group.  It's an IETF working group
designing a policy-neutral mechanism for this (WS in PAWS stands for
white space, the colloquial name for dynamic spectrum access).  

Both FCC in US and OFCOM in UK are designing policies so we hear from
some of them in the PAWS e-mail thread now and then.

---

From: Roland Bless <[email-masked]>
Date: Fri, 02 Aug 2013 10:32:18 +0200

Hi,

On 01.08.2013 09:11, Alison Chaiken wrote:
> Emmanuel Baccelli <[email-masked]
> <mailto:[email-masked]>>

Not yet, but BMW is using IP already in its on-board networks.
We had a national project (SEIS) that worked on the introduction of IP
into on-board networks. Getting rid of all those different bus systems
and heterogeneous protocols would simplify the network architecture a
lot. There are several reasons why you would like to have IP on top of
Ethernet...

> displacing the expensive FlexRay (essentially a TDMA variant of
> Controller Area Network) and CAN (collision-detection with bus priority
> arbitration).   Within GENIVI automotive consortium (about 170 car
> companies and suppliers), the arguments against IPV6 for "internode
> communication" are also about the size of data payloads versus header
> overhead similar to Dick Roy's

Optimizing too early and at the wrong end IMHO...

>   The PKE model of DSRC, with its reserved safety channel and reserved
> PSIDs, seems pretty appealing for safety applications.

Security by obscurity? Sure, on the one hand IP knowledge and attack
tools are more widely available, on the other hand the security
mechanisms like IPsec/DTLS and so on are proven to work well.

Regards,
 Roland