Subject: [ipwave] Should the IPWAVE WG adopt draft-jeong-ipwave-vehicular-networking-survey?

From: Russ Housley <[email-masked]>
Date: Tue, 6 Jun 2017 09:59:31 -0400

The IPWAVE WG charter calls for the group to publish an Informational document:

   This group will work on an informational document
   that will explain the state of the art in the field and describe
   the use cases that will use IPv6 in order to focus the work of
   the group.

Should the IPWAVE WG adopt draft-jeong-ipwave-vehicular-networking-survey
as the starting point for this deliverable?

See https://datatracker.ietf.org/doc/draft-jeong-ipwave-vehicular-networking-survey/

Russ

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 6 Jun 2017 16:27:30 +0200

I support adoption.

The 'Intended status' on the first page should say INFORMATIONAL.

Maybe some other use-cases could be added, or no.

Alex

Le 06/06/2017 à 15:59, Russ Housley a écrit :
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its
>

---

From: Nabil Benamar <[email-masked]>
Date: Tue, 6 Jun 2017 14:57:14 +0000

I support the adoption of this draft.

Best regards
Nabil

---

From: José Santa Lozano <[email-masked]>
Date: Tue, 6 Jun 2017 17:00:37 +0200

Me too.

Regards,

> El 6 jun 2017, a las 16:57, Nabil Benamar <[email-masked]> escribió:
> 
>> On Jun 6, 2017 14:27, "Alexandre Petrescu" <[email-masked]> wrote:
>> I support adoption.
>>

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 20 Jun 2017 17:32:09 +0200

Hi,

So far we have only received 3 opinions on this adoption. Please,
express your opinion (in favor or against adoption, preferably with
some comments in both cases).

Thanks!

Carlos & Russ

---

From: <[email-masked]>
Date: Tue, 20 Jun 2017 16:49:10 +0000

Dear chairs,
I am in favor of adopting the draft as starting point for the WG chartered informational RFC since it has much on state of the art in the field of vehicular communication - although IMO it could/should be further extended (to include e.g. 3GPPs LTE-V) and describe typical use cases in more detail (platooning is just mentioned once) ...

Best Regards
Dirk 

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Carlos Jesús Bernardos Cano
Sent: Dienstag, 20. Juni 2017 17:32
To: Russ Housley; its
Subject: Re: [ipwave] Should the IPWAVE WG adopt draft-jeong-ipwave-vehicular-networking-survey?

Hi,

So far we have only received 3 opinions on this adoption. Please, express your opinion (in favor or against adoption, preferably with some comments in both cases).

Thanks!

Carlos & Russ

---

From: Rex Buddenberg <[email-masked]>
Date: Tue, 20 Jun 2017 09:59:14 -0700

Russ, et al,

As a _survey_, this ID is fine.  There is value in simply cataloging
the somewhat scattered efforts in one place.  So I'm thinking we should
adopt as 'state of the art in the field'.  So I guess I'm ^ vis
adoption.
     But there are no use cases in the ID itself, only some of the
references.  Therefore the ID does not meet the charter call.  ... at
least not yet.
     Further, there doesn't seem to be much of a sorting model or
taxonomy.  What the ID does not cover (and was not Jeong's intent) is
what is needed but not present.  The use cases should lead to a
taxonomy and eventually an architecture -- should those signposts be
present?  Or is this a proper subject for agenda bashing external to
this draft?

b

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 20 Jun 2017 19:24:05 +0200

Dear Rex,

> present?  Or is this a proper subject for agenda bashing external to

Your point is very valid. The use cases should be covered by the
document that the WG is chartered to produce. This does not mean that
the current candidate draft can be adopted as this stage and the use
cases then be added once the document is under the WG control. I read
your mail as supportive of adoption of the draft with this assumption.
Please correct me if this is not the case.

Regarding the architectural work that might be triggered by the covered
use cases, that could be discussed at a later stage, once the WG has
met all the milestones (or is close to do so) and if the ADs consider
it appropriate.

Thanks,

Carlos

> > The IPWAVE WG charter calls for the group to publish an
> > Informational
> > document:
> > 
> > See https://datatracker.ietf.org/doc/draft-jeong-ipwave-vehicular-n
> > et
> > working-survey/
> > 
> > Russ

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Wed, 21 Jun 2017 06:56:14 +0900

Hi Rex,
As you mentioned, the revision of this draft will include the papers for
use cases that are based on
vehicular networking as follows:
------------------------------------------------------------------------------
Hwang T and Jeong J., "SANA: Safety-Aware Navigation
Application for pedestrian protection in vehicular networks",
In: Proceedings of the 2nd international conference
on internet of vehicles (IOV), Chengdu, China, 19–21
December 2015, pp.127–138. Switzerland: Springer

Kim J, Jo Y and Jeong J., "Design and evaluation of a
smartphone-based alarming system for pedestrian safety
in vehicular networks", In: Proceedings of the 2nd international
conference on internet of vehicles (IOV), Chengdu,
China, 19–21 December 2015, pp.221–233. Switzerland:
Springer.

Shen Y, Jeong J, Oh T, et al., "CASD: a framework of
context-awareness safety driving in vehicular networks",
In: Proceedings of the 30th international conference on
advanced information networking and applications
workshops—device centric cloud (DC2), Crans-Montana,
Switzerland, 23–25 March 2016, pp.252–257.

Koukoumidis E, Peh L-S and Martonosi M. "SignalGuru:
leveraging mobile phones for collaborative traffic signal
schedule advisory", In: Proceedings of the 9th international
conference on mobile systems, applications, and services
(MobiSys), Washington, DC, 28 June–1 July 2011,
pp.127–140. New York: ACM.

Jeong J, Jeong H, Lee E, et al., "SAINT: self-adaptive
interactive navigation tool for cloud-based vehicular traffic
optimization", IEEE Transactions on Vehicular Technology, 2016; 65(6):
4053–4067.
------------------------------------------------------------------------------

Thanks for your comments.

Best Regards,
Paul

-- 
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: [email-masked], [email-masked]
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>

---

From: Rex Buddenberg <[email-masked]>
Date: Tue, 20 Jun 2017 21:18:45 -0700

Paul,

Use case:

---------------------------

Instrumented emergency vehicle use case

Emergency vehicles include ambulances, fire engines, police cruisers,
snowplows and more.  The reason for isolating this use case is that
this class of vehicles shares the communications requirements of all
vehicles but has some more and more extreme requirements.  In many
cases, meeting the requirements for emergency vehicles will result in
exceeding the requirements for the family sedan.

Scenario.  

Consider an ambulance with one or more casualties inside.  These
patients will have vital signs monitors attached to them.  The
ambulance itself needs to deliver the casualties to a hospital.  The
ambulance, of course, must navigate in traffic – a characteristic of
most scenarios but with urgency attached.

- a LAN within the vehicle has the patient monitors attached to
it.  Additionally, the ambulance attendant would need at least one
attachment in order to speak with an emergency room doctor.  The
requirement is to telemeter the casualties' vital signs to the hospital
and over-shoulder advice from the ER doctor to the attendant.

- the driver needs communications with dispatching to telemeter track
data (position), receive dispatching orders, telemeter vehicle data
(e.g. gas tank level).

- the ambulance needs to communicate with other vehicles on the
road.  Collision avoidance, right-of-way warning (i.e. siren), traffic
light control.

While using an ambulance as example, all emergency vehicles have
similar needs.

Requirements distillation:

Security.  All data in the above illustrations must be verifiably
authentic.  Some data (such as the patient vital signs) requires
confidentiality.  In some cases (e.g. police car stakeout) low
probability of detection of the radio-WAN communications is required.  

Availability.  Most automotive applications require high availability
(Ao defined as up time divided by total time), emergency services are
the most demanding.  Typically four 9s.  This requirement cannot
usually be met with a single radio-WAN; multiple WAN interfaces on the
routers required, with the appropriate protocol capabilities.

-------------------------------------------

Not a formally published paper, but the draft doesn't require that.

On Wed, 2017-06-21 at 06:56 +0900, Mr. Jaehoon Paul Jeong wrote:
> Hi Rex,
> As you mentioned, the revision of this draft will include the papers
> for use cases that are based on
> On Wed, Jun 21, 2017 at 1:59 AM, Rex Buddenberg <[email-masked]
> m> wrote:
> > Russ, et al,
> > 
> > > Should the IPWAVE WG adopt draft-jeong-ipwave-vehicular-
> > networking-
> > > survey
> > > See https://datatracker.ietf.org/doc/draft-jeong-ipwave-vehicular
> > -net
> > > working-survey/
> > >
> > > Russ

---

From: Chris Shen <[email-masked]>
Date: Wed, 21 Jun 2017 13:53:30 +0900

Hi, all:

Thanks,
Chris.

-- 

Yiwen (Chris) Shen, Ph.D Candidate
IoT Lab: *http://iotlab.skku.edu <http://iotlab.skku.edu/>*
Sungkyunkwan University, Suwon, South Korea
Mobile:+82-(0)10-6871-8103
Email: [email-masked]

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Wed, 21 Jun 2017 15:07:10 +0900

Rex and Carlos,
The IPWAVE problem statement draft has already included use cases for V2I
and V2V networking:
Problem Statement for IP Wireless Access in Vehicular Environments
(draft-jeong-ipwave-problem-statement-00)
https://tools.ietf.org/html/draft-jeong-ipwave-problem-statement-00

I believe that the use cases suggested Rex and others can be included into
this problem statement draft
in the next revision.

I think that the survey draft can include the published use cases as
suggested by me.

What do think about this?

Thanks.

Best Regards,
Paul

---

From: Tony Li <[email-masked]>
Date: Wed, 21 Jun 2017 07:55:30 -0700

Rex,

What in this use case requires IP?  More specifically, what’s required beyond simple connectivity?

We need specificity if use cases are to be constructive.

Tony

> On Jun 20, 2017, at 9:18 PM, Rex Buddenberg <[email-masked]> wrote:
> 
> Paul,
> 
> Use case:
>

---

From: Rex Buddenberg <[email-masked]>
Date: Wed, 21 Jun 2017 08:36:44 -0700

Tony,

IP.  The telemetering of data to the hospital is an example of at least
a three-segment internetwork.  Terrestrial WAN, radio-WAN and LANs.  In
my book that makes a pretty good case for IP.  (The emergency services
comms folks tend to view the 'backhaul', the terrestrial WAN, as an
afterthought.)

Different.  Volatile topology and security.  

On Wed, 2017-06-21 at 07:55 -0700, Tony Li wrote:
> > > ---------------------------------------------------------------
> > > ----
> > > -----------
> > > ---------------------------------------------------------------
> > > ----
> > > -----------
> > > 
> > > > the somewhat scattered efforts in one place.  So I'm thinking
> > > > we
> > > > should
> > > > references.  Therefore the ID does not meet the charter
> > > > call.  ...
> > > > at
> > > > least not yet.
> > > > taxonomy.  What the ID does not cover (and was not Jeong's
> > > > intent)
> > > > is
> > > > taxonomy and eventually an architecture -- should those
> > > > signposts
> > > > be
> > > > present?  Or is this a proper subject for agenda bashing
> > > > external
> > > > to
> > > > this draft?
> > > > 
> > > > b
> > > > 
> > > >

---

From: [email-masked]
Date: Wed, 21 Jun 2017 09:05:46 -0700

Rex,

> comms folks tend to view the 'backhaul', the terrestrial WAN, as an

Those of us from the Internet infrastructure world are used to being an afterthought.  Except at the IETF. ;-)

I think that we can easily stipulate IP connectivity as a requirement, otherwise we wouldn’t be here, so I’m interested in more details.

> Different.  Volatile topology and security.  

We’ve dealt with volatile last-hop topology before (e.g., Wi-Fi).  What’s different here? Does your use case require multiple radio hops? 

On the security front, we won’t be fixing the security infrastructure of the entire Internet here, so there’s a limit to what we can do.  What do you see as the requirements that come out of your use case and how do existing IP security mechanisms align with or fail to meet those requirements?

Tony

---

From: Rex Buddenberg <[email-masked]>
Date: Wed, 21 Jun 2017 09:53:57 -0700

> an afterthought.  Except at the IETF. ;-)

The EMS community is used to VHF Land Mobile Radio with fairly high
power.  All the routable radio-WAN technologies feature much lower
power and therefore more dense networks of base stations.  The attitude
has to change.
> 
> I think that we can easily stipulate IP connectivity as a
> requirement, otherwise we wouldn’t be here, so I’m interested in more
> details.

What details?  There are about 20k jurisdictions across the US, each
with own purchasing capability.  So there are lots and lots of
details;-).  
    Probably THE characteristic is that EMS has two comms systems. The
first one is the one you and I use to call 911 to report a fire in the
house.  The second one is the above-mentioned LMR system which is
unique to EMS (and chronically obsolescent and underfunded).  There is
no particular reason for the two systems other than 'this is the way
we've always done it'.  The cry from the EMS folks has to do with QoS
which is technically bogus but emotionally potent.
> We’ve dealt with volatile last-hop topology before (e.g., Wi-
> Fi).  What’s different here? 

Topology.  The radio-WAN is a router-router arrangement (WAN) rather
than router-end system (LAN).  Which means that contention MACs are
unsuitable. This is a layer 2 issue and therefore outside IETF.  

> Does your use case require multiple radio hops? 

Certainly in some cases.  One of my sounding boards was in the business
in Wyoming where this is likely.  
   The anecdote here was that Wyoming was losing more snowplow
operators to operations than they were cops.  The typical scenario
would be a big semi overtaking a snowplow on I-80 during a snowstorm.
The truck would get too close before the driver understood the
situation and would rear-end the plow.  Good on-ice observation for
some of the v-v stuff.  

> 
> On the security front, we won’t be fixing the security infrastructure
> of the entire Internet here, so there’s a limit to what we can
> do.  What do you see as the requirements that come out of your use
> case and how do existing IP security mechanisms align with or fail to
> meet those requirements?

IMHO, most of the security requirements are content security
requirements, not infrastructure ones.  And they are end-end in scope.
This means that they should be solved at layers 6/7.  Which means that
authenticity and, when needed, confidentiality, should be built into
applications.  S/MIME e-mail offers some good clues.
     The 1609 folks harp about minimum latency.  And probably with
about the best reasons.  Like the snowplow radioing out a 'virtual
siren' that the semi can receive even in lousy vis.  That message has
to be authentic but it shouldn't require a three-way handshake, meaning
TLS is unsuitable.

> Help?

b

---

From: Russ Housley <[email-masked]>
Date: Fri, 23 Jun 2017 14:34:03 -0400

We have support for adoption of this Internet-Draft; however, the discussion has raised some topics that need to be worked on.

The current I-D says:

 This Internet-Draft is submitted to IETF in full conformance with the
 provisions of BCP 78 and BCP 79.

So, I ask that the authors ensure that any needed IPR statements are
posted prior to the posting of a draft-ietf-ipwave-vehicular-networking-survey-00.

Russ & Carlos

> On Jun 6, 2017, at 9:59 AM, Russ Housley <[email-masked]> wrote:
>