Subject: Re: [Roll] Fwd: I-D Action:draft-wakikawa-roll-invehicle-reqs-00.txt

From: Ryuji Wakikawa <[email-masked]>
Date: Thu, 5 Jun 2008 10:24:19 +0900

Hello Miguel,

Thanks for your comments.

On 2008/05/31, at 3:50, Miguel Sanchez wrote:

> Hi Ryuji,
>
>
> Here you have my comments.
>
> On page 8, Body Network: you mention air-bag control and 100msec  
> latency. However,  you later refer to the power train latency for  
> the air-bag control (from 2 to 6 msec).

OK, the document was not clear on this.
100msec latency is required for most of devices in the body network.  
The air-bag control is an exception in the body network.

> Next, on Infotainment Network: you mention a latency of 100msec  
> (including phone communication) but as you put Electronic Toll  
> Collection on the same network you later admit that latency for that  
> has to be much lower.
>
> I find these two cases above confusing: having a certain latency for  
> some services but one. (Not sure 100msec for the hands-free is going  
> to be comfortable either).

right.
Section 2.2 tries to describe the current in-vehicle network.
The current in-vehicle network (bus system) is specially designed to  
meet the required latency per services.
The category of in-vehicle network described in Section 2.2 are the  
typical classification in vehicle industry.

I will separate some exceptions such as air-bag and ETC from these  
category.

> Page 10, Path reliability: What is that? I know what you mean but  
> you may want to elaborate on this concept.

Two things I had in my mind are

1. link quality is considered as a metric of ROLL routing
2. try and error approach to detect the route errors might not be  
appropriate for some services.

> Page 13, Security:  For encryption, key management needs to be  
> addressed.

right. We will add the texts for the key management in the next  
revision.

thanks,
ryuji

> Regards,
> Miguel Sánchez

_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: Ryuji Wakikawa <[email-masked]>
Date: Thu, 5 Jun 2008 10:35:11 +0900

Hello Kim,

Thanks for comments.

On 2008/06/04, at 13:25, 김미점[USN연구담당] wrote:
>
> Hi, Ryuji,
>
> (Hi, everyone, this is my very first posting. I hope we have more  
> chances to discuss all ROLL things through the mailing list.)
>
> I found out this document is pretty interesting since I am not so  
> familiar with the subject and it gives me quite good lessons.  
> However, I also consider it needs to clarify some issues and be more  
> elaborate. Here are my tips.
>
>
> 	• 2.3. In-Vehicle Network Size: I don’t think very specific  
> vehicle size needs to be presented here since all are aware of rough  
> sizes of various vehicles and routing protocol is not that much  
> sensitive to the exact network size. And, I am not quite sure that  
> this kind of document is fine to mention or refer the specific  
> product name or model like LEXUS and Toyota.

OK.
We try to explain the node density is extremely high compared to other  
scenarios.
We can remove the example spec. no intention to promote toyota  
vehicles in IETF;-)

> 	• 3.1. Low Power: you mentioned un-powered devices, but I believe  
> all devices should be powered to operate. So I think you may be  
> confused with battery-powered devices.

:-)
right, we will fix this.

> 	• 3.7. Network Convergence: the explanation in the first paragraph  
> is about route recovery. I understand what you mean with network  
> convergence, but I still think, for routing requirements, network  
> convergence is not so proper term rather than route recovery. And  
> the second paragraph is not that related to routing requirements.

ok

> 	• 3.8. Manageability: auto-configuration is required in some LLN  
> scenarios, but routing protocol is not responsible for auto- 
> configuration or directly related to it. I think “routing protocol  
> should be extensible for new devices” is enough for the explanation.
> 	• 3.9. Mobility: there are different kinds of mobility. I think it  
> is better to mention node mobility rather than mobility. And in the  
> last line, “to adequate condition for each device” is not well  
> understood for me. Could you explain?

The last line indicates that
when the condition of a route path is changed, the ROLL routing should  
change the path to fulfill the service requirements (ex. latency).

> 	• 3.10 Security: This subsection seems to describe just general  
> security issues in wireless networks not specific to routing  
> requirements for LLN. It is needed more specific security concerns  
> for routing requirement such as encryption of routing control  
> messages or nodes in the selected path which need to be authenticated.

Thanks for all your comments.
We will update the document (hopefully before Dublin).

regards
ryuji

>
> I am expecting your opinion on the above my comments.
>
> Thank you.
>
>
> -----------------------------------------------------------------------------
> Kim, Mijeom, Ph. D, P.E.
> Senior Researcher
> USN Service Division
> Future Technology Laboratory, KT, South Korea
> Tel. +82-2-526-6063
> Cell. +82-10-9883-4951
> E-mail: [email-masked], [email-masked]
> -----------------------------------------------------------------------------
>
>
> -----원본 메시지-----
> 보낸 사람: "Ryuji Wakikawa" <[email-masked]>
> 보낸 날짜: 2008-05-29 오후 6:48:21
> 받는 사람: "[email-masked]" <[email-masked]>
> 참조: "[email-masked]" <[email-masked]>
> 제목: [Roll] Fwd: I-D Action:draft-wakikawa-roll-invehicle- 
> reqs-00.txt
>
> Hello all,
>
> We published a new requirement document for ROLL routing protocols.
> Although an in-vehicle network is not currently chartered in WG,
> we are very interested in ROLL activity for the future automobile.
>
> As Jukka  mentioned, some requirements are very similar to other
> requirements documents.
> We tried to highlight the differences in the document.
>
> Any feedback will be appreciated.
>
> thanks,
> ryuji
>
> Begin forwarded message:
>
> > From: [email-masked]
> > date: 2008/5/2918:30:01:JST
> > To: [email-masked]
> > Subject: I-D Action:draft-wakikawa-roll-invehicle-reqs-00.txt
> > Reply-to: [email-masked]
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> >
> >       Title           : In-Vehicle Routing Requirements in Low  
> Power and
> > Lossy Networks
> >       Author(s)       : R. Wakikawa, H. Kuwabara
> >       Filename        : draft-wakikawa-roll-invehicle-reqs-00.txt
> >       Pages           : 20
> >       Date            : 2008-05-29
> >
> > This document presents the routing requirements for in-vehicle low
> > power and lossy networks.  Automobiles are already equipped with
> > several sensors and devices named Electronic Control Unit (ECU) for
> > controlling, monitoring and entertainment, etc.  For the future in-
> > vehicle networks, the shift to wireless is desirable due to heavy
> > weight and volume of cables in vehicles and to be able to  
> efficiently
> > install devices.  However, with the limitation of low power, in-
> > vehicle network still requires reliability and scalability in nature
> > of the rolls of ECU.  The routing protocol should support the
> > features of low-power, high-reliability, Subnetting, QoS, Mobility,
> > etc.  This document briefly explains the in-vehicle networks and
> > ECUs, then discusses the requirements for the future wireless in-
> > vehicle networks.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-wakikawa-roll-invehicle-reqs-00.txt
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 09 Jun 2008 15:03:34 +0200

Ryuji Wakikawa wrote:
> OK, the document was not clear on this. 100msec latency is required
> for most of devices in the body network. The air-bag control is an
> exception in the body network.

As a side note, humans are typically feeling 'instantaneous' reaction
when pressing a button if it takes less than 50ms to happen.  Examples
are: top of the line SLR camera actuators are around 50ms, piano key
action requires in the order of 5ms and less to feel natural.

Bluetooth 128kbps audio streaming has very high latency, hundreds of
milliseconds, un-adapted to phone conversations, but ok for mp3 music
playing.

I'm not surprised the airbag control requires 2-6msec and I'd even like
it to be much shorter to feel safer at higher speeds :-)  It's
interesting to note that a WiFi link could ensure 1ms latency and even
less (ping on 802.11g goes down to 30useconds).  However, I feel
somewhat unsure about using wifi to trigger the airbag shot, I'm not
sure what, but something.

Alex

>> Collection on the same network you later admit that latency for
>> that has to be much lower.
>> 
>> I find these two cases above confusing: having a certain latency
>> for some services but one. (Not sure 100msec for the hands-free is
>> going to be comfortable either).
> 
> right. Section 2.2 tries to describe the current in-vehicle network. 
>  meet the required latency per services. The category of in-vehicle
> network described in Section 2.2 are the typical classification in
> vehicle industry.
> 
> 1. link quality is considered as a metric of ROLL routing 2. try and
> error approach to detect the route errors might not be appropriate
> for some services.
> 
> thanks, ryuji
> _______________________________________________ Roll mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/roll
> 

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________
_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll