Re: [ipwave] use-cases in Problem Statement

Abdussalam Baryun <abdussalambaryun@gmail.com> Thu, 18 April 2019 03:08 UTC

Return-Path: <abdussalambaryun@gmail.com>
X-Original-To: its@ietfa.amsl.com
Delivered-To: its@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2569120099; Wed, 17 Apr 2019 20:08:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZvxujmZpLf3; Wed, 17 Apr 2019 20:08:20 -0700 (PDT)
Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A01D4120294; Wed, 17 Apr 2019 20:08:20 -0700 (PDT)
Received: by mail-ot1-x330.google.com with SMTP id e5so467517otk.12; Wed, 17 Apr 2019 20:08:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=066BObWJ/oe/1UExk2sXFQnKN59o0yOGZM2K6Oy//OI=; b=dXAcpgB8IGOrYBcRFxw20qG6MMdnjeYsgnN+i8fpY5FjN4/rzyUDJCxt2VUU2zZghE BviEQ3nFYh5TG/vYdyDbgEFk7x1U36bKISncj5jLKny4UcfNnXnmCBmDDTYuYLQ6jGt/ uPayV5QWKSY0rJeKjJppZYAacBodbrbEwQoaDdYexaGGZtl2Z/IQaa1xMjelkPnIwOAu shkQxNvyGtosO4ENal/FdSVBa78X4jdt1ae4Qc7dX0AHy3SfLX2Fwc8OgRUFX3sfDO+I g3+lF9U6WQgeftk5SyNNhXKeRE0LdJ3765VESlhAhPkWzvxsAhTC0uDZpzHlj52HeYBr TPWg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=066BObWJ/oe/1UExk2sXFQnKN59o0yOGZM2K6Oy//OI=; b=pKObPILBTgUM64roea5Ap2yirs+4rVAS5hSAHu5vOMORTOr7d93iSSg9hv71VZIHJh J2vAYQxiZTFLuZvNyUN7LUB5CsoSP02r0/7uGTtO3kXBH64smoIxaZDXZ3KqOCCc1FHy 0/3nvhYxO/VXzgKIdh6CR0PMPdjDp6msHr3bxwe1OWeL0mKoPVgSCuddrArCGOvnsINQ 1tzn9/zdHQXcTUidp3z2b4QHfQp6d6/g1FpctKuexrFW/q7TryjPOBqBbhi6YxWxD0o8 Dom61Fciq2O+7R4mh3OlcVpbf7pYS1jQhYCxztQC34JgT8l7DYUUkTVzN7gSeKXfbCl5 140w==
X-Gm-Message-State: APjAAAXGovP0FjRCH1LyPJ0CdmbnBxUPrBuJZG1vOhj1WLuUno/Ex8ci HMg1zSY82Phyu3QAFpltss7/BFL17VEu/6KCUQE=
X-Google-Smtp-Source: APXvYqxyIHNnKpZxdmPPpTXXqCoDC0xXbA/2zFJVzi2k/bJIhtekZNkJpVnWKSRzMsTHJkOkxoKvFHXNJaaAJljr4sQ=
X-Received: by 2002:a9d:7359:: with SMTP id l25mr57357282otk.189.1555556899982; Wed, 17 Apr 2019 20:08:19 -0700 (PDT)
MIME-Version: 1.0
References: <155169869045.5118.3508360720339540639@ietfa.amsl.com> <a8aad636-069c-4451-dbf1-72c1db2204ef@gmail.com> <CAD8vqFfx_FVi5NobrR1p6xEKjkSNa1_ZejgrEs3JPDHJQoxD7A@mail.gmail.com> <MN2PR11MB356570FDBC5798F155DDEE25D82C0@MN2PR11MB3565.namprd11.prod.outlook.com> <CAMugd_Xce5cWLtVB4DbR1ZEaFbdfiRpXre9oq61ukRC+n+3cZw@mail.gmail.com> <D8D5F0B7.2F2BB8%sgundave@cisco.com> <D8D5F510.2F2BC8%sgundave@cisco.com> <3e716b4b-8236-0488-309c-7cd3a54db7b5@gmail.com> <D8D7B1E7.2F2CA2%sgundave@cisco.com> <CAD8vqFfSGKhw_ou3VB98C8r1gq=4WD8+f8C5P53C46k-0V+XuA@mail.gmail.com> <66e7c810-45a5-5244-59dc-4b764b6fb346@gmail.com> <1a6599ee-88f9-42d9-a208-918ba6711612@gmail.com> <11645738-6f95-82e5-48f1-ebc3ce54423e@gmail.com> <0ae10089-4b1a-f85c-1a3d-15e712cb7547@gmail.com> <084449fd-2693-0cfb-6589-0cf67cf9ffe6@gmail.com> <D8DA8E15.2F2F73%sgundave@cisco.com> <efaf44b5-755e-6a9c-c85e-916e72638fae@gmail.com>
In-Reply-To: <efaf44b5-755e-6a9c-c85e-916e72638fae@gmail.com>
From: Abdussalam Baryun <abdussalambaryun@gmail.com>
Date: Thu, 18 Apr 2019 05:08:03 +0200
Message-ID: <CADnDZ888MzgngcrvamETg0RTBCW=v5SeXpDVpB=6c-S_NCKBJA@mail.gmail.com>
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Cc: "Sri Gundavelli (sgundave)" <sgundave@cisco.com>, NABIL BENAMAR <n.benamar@est.umi.ac.ma>, "its@ietf.org" <its@ietf.org>, "draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org" <draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org>, nabil benamar <benamar73@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000007390150586c55045"
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/M_IWH3WNBv79CMa9_xpUFAs8EtY>
Subject: Re: [ipwave] use-cases in Problem Statement
X-BeenThere: its@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF <its.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/its>, <mailto:its-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/its/>
List-Post: <mailto:its@ietf.org>
List-Help: <mailto:its-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/its>, <mailto:its-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Apr 2019 03:08:24 -0000

On Wed, Apr 17, 2019 at 1:13 PM Alexandre Petrescu <
alexandre.petrescu@gmail.com> wrote:

>
>
> Le 16/04/2019 à 05:11, Sri Gundavelli (sgundave) a écrit :
> >> I am no expert, but I do know some physics, and it seems pretty
> >> clear to me that if there are multiple lanes of traffic, a large
> >> truck can easily shield signals between two cars and the shielding
> >>  will be intermittent, regardless of how much wireless power is
> >> allowed, depending on traffic movement. So it's a highly dynamic
> >> mesh network.
> >
> >
> > Part of the problem is that we have not clearly put some limits on
> > the use-cases. These unbounded limits is opening up these discussions
> > on ad-hoc full mesh network formations and the resulting challenging
> > ND scenarios. But, again I always assumed this discussion is for the
> > ND document and there should be no bearing on this document.
> >
> > V2X communications involves V2V, V2I and V2P communication modes.
>
> For the term V2P (Vehicle to Pedestrian) I would like to suggest
> addition of term VRU as well: Vulnerable Road Users.  I suggest the new
> term V2VRU: Vehicle to VRU.
>

two V in V2VRU with different meanings and many symbols may confuse new
users, as V2V both V same meaning. I hope we make it three symbols as V2V,
V2X,..


>
> VRUs dont have OCB interfaces (smartphones's wifi interfaces cant be set
> at 5.9GHz), yet they are at most risk since they are not protected by
> cages like the  automobiles are.
>
> V2VRU is a problem, because OCB-equipped vehicles can communicate to
> OCB-free VRUs only by means of high-latency cellular network (50ms 4G vs
> 1.5ms OCB).  In safety, lower latency is preferred over higher latency.
>

that is important,


> I would like to suggest the above addition in the Problem Statement
> draft, section 3 "Use Cases".
>

I agree,


>
> > From the point of view of vehicular safety, its about exchange of BSM
> > (Basic Safety Messages) between vehicles as per SAEJ735 standard.
> > These safety communications is always one-hop communication and for
> > very good reason IEEE WAVE standards did not bother to require IPv6
> > transport for carrying these messages. The WSMP message which carries
> > these safety elements are defined to be carried over layer-2
> > payloads. Personally, I never thought we will replace this L2 safety
> > communication mode with layer-3 mode (IPv6-over-80211-OCB). But the
> > use of IPv6 is more for allowing applications in the vehicle to
> > communicate with the infrastructure. For example, a vehicle using
> > DSRC radio to access some traffic application in the cloud.
> >
> > In one sense, this is like a mobile node using 802.11-OCB like any
> > other radio technology (CDMA, LTE, Wi-Fi), and use IPv6 for its
> > communications. In this context, its always about vehicle to
> > infrastructure communications.
>
> I would like to suggest addidion of text about "BSM" in the Problem
> Statement draft.
>
> The localisation corrections are highly needed in OCB, potentially with
> BSM and/or other V2X message.
>

Agree,


>
> > Now, there are other interesting peer to peer use-cases, where one
> > vehicle is streaming some video to another vehicle without using any
> > infrastructure.
>
> I would like to suggest to add in section "V2V" in the Problem Statement
> draft the following text:
>
> NEW:
> > o  see thru: streaming video from one vehicle to another vehicle
> > without using any infrastructure, to see through obstacles
>
>
>
> > While these later examples are very cool, personally, I did not
> > expect this WG to solve those use-cases day-1.
>
> I would like to suggest the addition of the term "day-1" to the Problem
> Statement draft.
>
> > For us to support those use-cases, we need to figure out many more
> > things including approaches for exchanges prefixes between two
> > vehicles that come in proximity. In my mind, these are very forward
> > looking and the only relevant application is platooning. I am not
> > interested in solving this V2V problem, but was more interested to
> > enable V2I communications, where the focus is about link model,
> > prefix hosting approaches, mobility support (building a large L2
> > domain over RSU’s, or routed approaches with mobile IP type
> > protocols) ..etc. In one realization, there may be a P2P link
> > assumption between the vehicle and the RSU, eliminating most of these
> > ND issues. But, those discussions are for the other document and that
> > clearly should remove these ND concerns from this document.
>
> I agree.
>
> Alex
>
> _______________________________________________
> its mailing list
> its@ietf.org
> https://www.ietf.org/mailman/listinfo/its
>