Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB- interoperability

From: Alexandre PETRESCU <[email-masked]>
Date: Thu, 1 Mar 2018 15:18:55 +0100

--
Alexandre Petrescu
[email-masked], tél 0169089223

Le 28/02/2018 à 23:19, Abdussalam Baryun a écrit :
>
>
> On Wed, Feb 28, 2018 at 4:08 PM, Alexandre PETRESCU 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>     --
>     Alexandre Petrescu
>     [email-masked] <mailto:[email-masked]>, tél 0169089223
>
>     Le 28/02/2018 à 14:58, Michelle Wetterwald a écrit :
>>     Hi Alex,
>>
>>     Answers inline.
>>
>>     2018-02-28 12:22 GMT+01:00 Alexandre PETRESCU
>>     <[email-masked] <mailto:[email-masked]>>:
>>
>>         [trimmed the CC because mailer problems]
>>
>>         Le 28/02/2018 à 11:34, Michelle Wetterwald a écrit :
>>
>>             Hi Alex,
>>
>>             Regarding the interoperability between different
>>             implementations, it has been fully validated during
>>             numerous plugtests events in EU and US, gathering a large
>>             set of different implementations. For the EU ones, the
>>             reports are freely available on the ETSI web site.
>>
>>
>>         I am using the wireshark dissectors on the ETSI web site.
>>
>>         I can tell they show lack of interoperability: several CAM
>>         messages from several stacks are not understood by these
>>         wireshark dissectors.
>>
>>
>>     Can you give references to these stacks?
>
>     github.com <http://github.com> 'rendits', 'vanetza', 'driveits',
>     'geonetworking', 'btpsap'.
>
>     None puts a QoSData header, each puts a 'Data' header.
>
>     (but none sends CAM as IP messages either).
>
>
> Any implementer uses the easy way to transmit, so future work 
> can develop it.
>
>
>
>>
>>         The ETSI wireshark dissectors have another problem
>>         themselves: they are not integrated in the main wireshark
>>         software.  It's just ETSI's point of view.
>>
>>             I am sorry to hear that the open source implementation
>>             that you are using has some limitations. I remember that
>>             one of the participants to the last PlugTest in Livorno
>>             (Nov 2016) explained to me he had extended the open
>>             source software to use his computer to monitor the
>>             traffic exchanged on the 802.11p. So he made his Ath
>>             implementation fully interoperable with those from the
>>             other vendors. Maybe you can apply similar upgrades to
>>             your testing implementations?
>>
>>
>>         Can you tell me who is that participant so I can contact?
>>
>>
>>     Sorry, NDA applies here. But the list of vendors is in the report.
>
>     The reference to the report please?
>
>>
>>             Again, I disagree with the change you propose in the text
>>             of the draft, as it goes against the *existing* EU
>>             regulations. Compliance with the modified text would
>>             prevent vendors from accessing the EU market.
>>
>>
>>         Accessing EU market is a good thing, but customer lock in may
>>         not be that good.
>>
>>
>>     This is not customer lock-in, there are several and diverse
>>     implementations available (BTW, this is more an L2 than an
>>     L3-IETF related topic), the only thing is that you have to pay
>>     for getting them, which is often part of the market rules, right?
>
>     There are software features in limited deployment that deserve a
>     certain amount of money.
>     But key aspects like running IP are free of charge.
>
>     For example, it is worth attaching a price tag for software in a
>     limited deployment (e.g. this highway), but IP is much wider
>     scale.  You cant put a price tag on it.
>
>>     Is there a requirement that an RFC can be approved only if
>>     several open source implementations are available?
>
>     No, there is no such requirement.
>
>
> There is no requirement, and it can be solved if required, so IMO we 
> should not ask for it because this draft is only transmission over.
>
>
>     But there is requirement for interoperability.  I can test for
>     interoperability because I can use some open-source stacks.
>
>
> The open source software are not standards or they are standards? if 
> not they may not follow our standards, and if yes they need to follow 
> the use requirement of ieee802.11-ocb

Open source is a good thing.  It was instrumental in validating many 
Internet Drafts before.

>
>     For one, they are not interoperable among themselves when it comes
>     to QoSData, but _are_ interoperable if they use Data.
>
>
> Why test results are not interoperable for QoS?

Because if someone sends QoS Data (like the proprietary V2X stacks) and 
other people send Data instead of QoS Data at the same time (like the 
open source implementations of IP-over-OCB, or like the open source 
implementations of V2X), there is no quarantee that the QoS expectations 
of the first be satisfied.

Alex

> AB