Re: [ipwave] Intdir last call review of draft-ietf-ipwave-vehicular-networking-20

Michael Richardson <> Thu, 09 September 2021 17:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7B6613A07AA for <>; Thu, 9 Sep 2021 10:10:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kcHVTUGFJZdI for <>; Thu, 9 Sep 2021 10:10:49 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0E4103A07A9 for <>; Thu, 9 Sep 2021 10:10:48 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id B93C1399EE; Thu, 9 Sep 2021 13:17:15 -0400 (EDT)
Received: from ([]) by localhost (localhost []) (amavisd-new, port 10024) with LMTP id fjyA2JOZaUti; Thu, 9 Sep 2021 13:17:10 -0400 (EDT)
Received: from ( []) by (Postfix) with ESMTP id A67283992B; Thu, 9 Sep 2021 13:17:10 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 15A5C8B4; Thu, 9 Sep 2021 13:10:42 -0400 (EDT)
From: Michael Richardson <>
To: Alexandre Petrescu <>,
In-Reply-To: <>
References: <> <> <> <>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Date: Thu, 09 Sep 2021 13:10:42 -0400
Message-ID: <20060.1631207442@localhost>
Archived-At: <>
Subject: Re: [ipwave] Intdir last call review of draft-ietf-ipwave-vehicular-networking-20
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 09 Sep 2021 17:10:52 -0000

{I'm not clued into all of this thread}

Alexandre Petrescu <> wrote:
    > Certainly, when experimenting with car networks many packets get lost,
    > and many errors show up.  But there are so many other causes for that
    > to happen, than what a protocol can deal with: the things that happen
    > have to do in many cases with human factors like the working conditions
    > (programmers are not sitted comfortably at a desk, but are
    > uncomfortably sit in cars with small screens small keyboards); then
    > there are so many intermediary layers of protocols which might fail,
    > and also the reporting which often fails.  These things generate a
    > majority of events that one might take for a 'lossy network'.

Before I knew that ITS was a thing (back around 2010), I was driving to
Boston from Ottawa alone. In the winter.  I don't drive much in general.
I had put my audio-book CD on the counter, but left it at home, so I had many
hours alone to think about mobile networks in automobiles.

    > For example, cars move on ways along pre-determined paths.  There might
    > be convoys, and sliding lanes of cars, there might be intersections
    > controlled by traffic lights; human reaction (in the order of 1 or 2

In the dark January blizzard in upstate Vermont, I was thinking a lot about
convoys of cars with connectivity among themselves, but no connectivity out.
Safe travel distances in those conditions mean ideally being far enough apart
to not be able to see tail lights.   Being able to get warnings of slowdowns
ahead for four or five cars ahead of me would be great.
But, I considered that the killer app was probably chat among the passengers.

RPL has a whole slew of "secured" versions of every message.  These have
proved uninteresting to current LLNs: too expensive to do asymmetric crypto
given energy budgets, and lack of deployed certificates.
Automobiles don't have either problem.
And they do have mutual distrust, and we can't do a "network-wide" PSK,
so we need to use the asymmetric versions of the RPL routing code.
I'm not aware of ISIS/OSPF having that feature.
BGP4 has it (RPKI), but I'm not convinced BGP4 has the right properties for a