Subject: [its] MTU and size of a typical CAM / DENM / ITS messages

From: Jérôme Härri <[email-masked]>
Date: Wed, 27 Jul 2016 12:23:30 +0200

Dear All,

Thanks Michelle for this details. I would like also to further add some details on the MTU discussion we had last week. 

The very existence of a MTU is not only to make or break the upper layers, but to guarantee reliable communication on the wireless PHY layer. One aspect that restricts the MTU is the wireless channel coherence time, say “the time-scale at which fading occurs”, (i.e. the time during which the channel will not change ‘much’). This might be less important for wired Ethernet, but critical for wireless Ethernet-style of networks, as it creates time-selective channels.

When a WiFi device receives a packet, it will use the OFDM pilot symbols (4 out of 52) to estimate the channel. This is done at the PHY preamble of packet only and never during the packet/payload reception (well, we can discuss the pertinence of this choice, but it is the case for 802.11a). If the channel does not change (residual phase error) much during the packet transmission from what has been ‘estimated’ during the preamble, then everything is fine. But if it does (narrowband fast fading), there is a high chance that the packet will be lost..

This justifies the fact that a packet should not take more ‘time’ than the channel coherence time during its transmission (to avoid time selectivity). The question is: what is the channel coherence time? Well, it differs a lot depending on the environment, but for WiFi in a quasi-static environment (~90% of WiFi traffic), it is usually quite long (order of multiple of ms). 

But on ITS-G5/DSRC/820.11p/…, studies indicated that it is approximatively 1ms (source: Measurement and Analysis of Wireless Channel Impairments in DSRC Vehicular Communications, Laberteaux et al, 2008). 

Said it simple: any ITS-G5/… packet being transmitted on the vehicular wireless channel that would take more than 1ms has a high(er) chance of being lost. ITS-G5/DCC/ITS applications will play with modulations (BPSK,…/64QAM) to enhance the modulation order and accordingly reduce the transmission time on channel (with as consequence an increased required SINR at the receiver, and thus a shorter distance (at least))..

So, the ITS-G5/802.11p/DSRC MTU can be big or small..it all depends on what I called at the IETF meeting the ‘equivalent transmit time on channel’. So, whatever would be the MTU from a PHY perspective, it should not take more than 1ms to be transmitted on the channel.

The control channel (ch 178 US, ch. 180 EU) fixed a compulsory modulation of 6Mbps (QPSK ½). This limits the MTU to  750 bytes (if my computations are correct..)..of course, you may always try to send a larger packet, but again, the channel might change ‘during’ the transmission of your packet and you might lose it. According to Michelle’s e-mail, such MTU is fine for CAM/DENM…

Now, if you want to send IPv6 traffic, and assuming the channel coherence time is 1ms, then you have to adapt the modulation to get bigger MTUs…So, I would support the conclusion of the discussion we had is that for IPv6 packets to be transmitted on ITS-G5/DSRC/802.11p/.., we should indicate a minimum MTU as required by IPv6 that should be delivered by ITS-G5/../….and ITS-G5 will try to get it by playing with modulation..If ITS-G5 cannot provide it for ‘any’ reason, then it just means the channel is not good enough for IPv6 at the moment, and it should delay its transmission. If IPv6 requires a bigger MTU, then it is the role of the ITS-G5 to notify IPv6 of the MTU-modulation-range(SINR) combinations, so that IPv6 can adjust the most appropriate MTU.

As Michelle mentioned (and supporting also Dieter), I would avoid fragmenting at the access technology layer..802.11a is not good at efficient fragmentation (but 802.11ac is J).

Best Regards,

Jérôme

From: its [mailto:[email-masked]] On Behalf Of Michelle Wetterwald
Sent: Wednesday 27 July 2016 11:19
To: [email-masked]
Subject: [its] Size of a typical CAM / DENM

Hello,

In parallel to the meeting last week, I asked some experts close to implementers. As mentioned during the meeting, the answer is not straightforward as it has to take into account the specifics of the ITS station, and several experts had to be consulted on this question. 
Indeed, the message size can be highly variable. After some investigation, the experts came to the conclusion that the CAMs without security are 100 to 600 Bytes long and the DENMs without security are typically between 300 and 800 Bytes long.

Hence, even with security, CAM and DENM will stay below 1500 Bytes length.

Furthermore, the experts confirm the opinion that fragmentation is no good idea. Other solutions, maybe at higher layers, have to be defined.

Thanks to Dieter Smely for his help finding the answer.

Best regards,
Michelle Wetterwald
----
Senior expert in networking and telecommunications

---

From: Jérôme Härri <[email-masked]>
Date: Wed, 27 Jul 2016 12:36:27 +0200

Dear All,

Additional corrected information related to the channel estimation: I was referring to the short and long training sequences of the PHY preamble, and not to the pilot OFDM in this case…sorry for the confusion. Conclusions/impacts remain the same.

Best Regards,

Jérôme

From: its [mailto:[email-masked]] On Behalf Of Jérôme Härri
Sent: Wednesday 27 July 2016 12:24
To: [email-masked]
Subject: [its] MTU and size of a typical CAM / DENM / ITS messages

Dear All,

Best Regards,

Jérôme

Hello,

Best regards,
Michelle Wetterwald
----

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 27 Jul 2016 16:05:07 +0200

Hi Jérôme,

Thanks for the message.

Le 27/07/2016 à 12:36, Jérôme Härri a écrit :
[...]
> So, the ITS-G5/802.11p/DSRC MTU can be big or small..it all depends
> on what I called at the IETF meeting the ‘equivalent transmit time
> on channel’. So, whatever would be the MTU _from a PHY perspective_,
> it should not take more than 1ms to be transmitted on the channel.

Out of that 1ms can we calculate the packet size that can be transmitted
during it?

> The control channel (ch 178 US, ch. 180 EU) fixed a compulsory
> modulation of 6Mbps (QPSK ½). This limits the _MTU to  750 bytes_ (if
> my computations are correct..)

Is the QPSK 1/2 modulation accepted in EU too?

> ..of course, you may always try to send a larger packet, but again,
> the channel might change ‘during’ the transmission of your packet and
> you might lose it.
>
> According to Michelle’s e-mail, such MTU is fine for CAM/DENM…

Well, one of the upper limits in Michelle's email is 800bytes (DENM
without security) and that is exceeding the 750bytes you mention above.

> Now, if you want to send IPv6 traffic, and assuming the channel
> coherence time is 1ms, then you have to adapt the modulation to get
> bigger MTUs…So, I would support the conclusion of the discussion we
> had is that for IPv6 packets to be transmitted on
> ITS-G5/DSRC/802.11p/.., we should indicate a _minimum MTU *as*
> required by IPv6_ that should be delivered by ITS-G5/../….

I agree.  The minimum MTU size that is required in order to support IPv6
is 1280bytes.  We will definitely write that down.

(for the term "minimum MTU" remark the abbreviation expands into
"minimum maximum transmission unit size", which led to some confusion
sometimes; but let's go with it for now).

> and _ITS-G5 will try to get it by playing with modulation_..If
> ITS-G5 cannot provide it for ‘any’ reason, then it just means the
> channel is not good enough for IPv6 at the moment, and it should
> delay its transmission.

This logic sounds more dynamic than I thought of.

You seem to be saying there is a variable MTU size, and buffering 
(rather than fragmentation) can be employed to adapt to the IPv6 MTU 
size in time.

I wonder whether that can be noticed in practice in the command line on 
linux?

> If IPv6 requires a bigger MTU, then it is the role of the ITS-G5 to
> notify IPv6 of the MTU-modulation-range(SINR) combinations, so that
> IPv6 can adjust the most appropriate MTU.

Is there a means by which ITS-G5 (aka 802.11-OCB) notifies the IP
networking layer about something?  An API?  A field in a header?

> As Michelle mentioned (and supporting also Dieter), I would avoid
> fragmenting at the access technology layer..

Do you mean MAC layer?

> 802.11a is not good at efficient fragmentation (but 802.11ac is J).

Err... the 802.11 Data Headers do feature a 'More Fragments' bit in the 
Flags byte of the Frame Control Field.  When that bit is '0' the text 
says 'This is the last fragment'.

It makes think fragmentation is 802.11, and not a matter of 802.11a or 
802.11ac.  You seem to say there is a difference?

Alex

>
>
>
> Best Regards,
>
>
>
> Jérôme
>
>
>
> *From:*its [mailto:[email-masked]] *On Behalf Of *Michelle
> Wetterwald *Sent:* Wednesday 27 July 2016 11:19 *To:* [email-masked]
> <mailto:[email-masked]> *Subject:* [its] Size of a typical CAM / DENM
>
>
>
> Hello,
>
> In parallel to the meeting last week, I asked some experts close to
> implementers. As mentioned during the meeting, the answer is not
> straightforward as it has to take into account the specifics of the
> ITS station, and several experts had to be consulted on this
> question. Indeed, the message size can be highly variable. After
> some investigation, the experts came to the conclusion that the CAMs
>  without security are 100 to 600 Bytes long and the DENMs without
> security are typically between 300 and 800 Bytes long.
>
> Furthermore, the experts confirm the opinion that fragmentation is
> no good idea. Other solutions, maybe at higher layers, have to be
> defined.
>
> Best regards, Michelle Wetterwald ---- Senior expert in networking
> and telecommunications
>
>
>
> _______________________________________________ its mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/its
>

---

From: Jérôme Härri <[email-masked]>
Date: Wed, 27 Jul 2016 19:20:07 +0200

Hi Alex,

Answers inline...

 [...]
>> So, the ITS-G5/802.11p/DSRC MTU can be big or small..it all depends on 
>> what I called at the IETF meeting the ‘equivalent transmit time on 
>> channel’. So, whatever would be the MTU _from a PHY perspective_, it 
>> should not take more than 1ms to be transmitted on the channel.

during it?

You need to fix one parameter: if you fix the modulation, then yes.
Otherwise, you fix the packet size and change the modulation.

>Is the QPSK 1/2 modulation accepted in EU too?

Yes, 6Mbps is also the default (and restricted) modulation on the CCH in EU.

>Well, one of the upper limits in Michelle's email is 800bytes (DENM without
security) and that is exceeding the 750bytes you mention above.

Ok, but as this is merely stochastic, we can exceed a bit (or even be at the
limit), it might still be OK (or even not work at lower packet size..). We
should avoid 'exceeding' 750Bytes...but it is all about channel
conditions..and if you are OK with retransmission in case of packet
losses...

>I agree.  The minimum MTU size that is required in order to support IPv6 is
1280bytes.  We will definitely write that down.

OK, great.

I will also further check if other studies mentioned different channel
coherence time (or if we could have classification of it as function of a
particular context..)

>(for the term "minimum MTU" remark the abbreviation expands into "minimum
maximum transmission unit size", which led to some confusion >sometimes; but
let's go with it for now).

Indeed.

>> channel is not good enough for IPv6 at the moment, and it should delay 
>> its transmission.

> You seem to be saying there is a variable MTU size, and buffering (rather
than fragmentation) can be employed to adapt to the IPv6 MTU size in > time.
linux?

Well, it is all dynamic in wireless...what I  mean is that MTU is a
conceptual representation in wireless. We need to identify a 'true'
parameter, and extract the MTU from it. My proposal was to use a 'transmit
duration', as this would also allow us to control the congestion...the 1ms
channel coherence time could be a guideline, but we could also get a
different value..

My point is it should be a channel 'usage time' rather than a 'packet
size'...

If you fix the channel usage time (ex. 1ms) per IPv6 packet, then it is
quite easy to extract the MTU for each modulation (8 in total)..so, this
could be a basic function that can be implemented..and available as API...

The ITS-G5 API can change the modulation, and the DCC (called channel
congestion control in the US) can also tell you how long you can use the
channel (in the case we would choose to use more than 1ms per IPv6 packet).
So, both parameters may be used. But the best option would be to have this
at the facilities layer (it is already being discussed at the ETSI ITS...so,
you could configure your IPv6 traffic accordingly (and not have to 'stop it'
below).

As mentioned, best would be to use a facilities layer, but if we want to use
plain IPv6 and ITS-G5, then you can have access to the ITS-G5 management
functions, there are command-line functions to retrieve or change modulation
or other things. 

But more generally, I think we will need a 'service management' message or
something similar..first (as mentioned also during the IETF meeting) as we
need to announce on which channel the IPv6 will be transmitted...but second
we can use this message to announce 1) the modulation and 2) the respective
MTU. 

This kind of management message was the duty of WiFi beacons...but as they
are not there for ITS-G5, we need to compensate with something...could we
have an IPv6 management message taking this role? 

>Do you mean MAC layer?

Yes...

>Err... the 802.11 Data Headers do feature a 'More Fragments' bit in the
Flags byte of the Frame Control Field.  When that bit is '0' the text says
>'This is the last fragment'.
>

This is not on the mechanism, but on the efficiency. 

.11a separates each fragment by a SIFS and must add a ACK after each unicast
fragment. And each fragment must have its MAC header, and as any MAC packet,
the header cannot have an increased modulation (BPSK 1/2 by default). So,
whatever you would do on the fragment (increasing modulation), you will be
limited by the fixed overhead given by the number of extra headers, the SIFS
and ACKs. Also, the mechanism can be seen as a monopoly on the channel. As
all fragment are transmitted after a SIFS, any other traffic will have
limited chances (or actually no chance due to virtual carrier sensing) to
even access the channel...

.11ac (starting already by .11n and even .11e as option) allows you to
optimize the fragmentation by transmitting a group ACK for all fragment, and
even reduce the time between fragment (RIFS < SIFS). As time on a wireless
vehicular channel is critical, we need to avoid such extra overhead.

btw, the maximum transmission length on 802.11ac is defined as 5ms (but I
could not find the equivalent for 11.a...maybe it is the same). 

Cheers,

Jérôme

---

From: Jérôme Härri <[email-masked]>
Date: Wed, 27 Jul 2016 19:24:19 +0200

Hi Alex,

I further found some baseline 802.11 metrics that could be of interest to
the draft:

.11a: maximum MAC Service Data Unit (MSDU - MAC payload...): 2 304 Bytes -
this is I think one of the values you mentioned in the presentation...I do
not think there was any protocol or physical limitations fixing it to 2304B.
What I found on some books is that it has been 'chosen' as such.. The idea I
think was to allow upper layers to transmit combinations of 256 bytes
(including extra headers..). Maybe somebody could find the true reasoning
behind this value...

The maximum length of a 802.11a embedded MAC frames on the PHY layer (so,
maximum PSDU) is encoded in 12 bits, giving a maximum length of 4048 bytes.

So, in theory, it could get higher than 1500 bytes..and as matter of fact,
if 802.11a allows up MSDU to 2304 bytes, 802.11ac allows up to 11 454
bytes...but keeping in mind that the maximum transmit time is 5ms...so .11ac
benefits from high modulation and wider bands.

In our case, 802.11-2012 for 5GHz fixes indeed 2304 as maximum MSDU, reduced
in practice to 1500 for IP traffic. 

Now, if we take a bottom up approach and fix transmit time to 1ms (instead
of 5ms), fix modulation to 6Mpbs and 10Mhz channel, then 'effective' PPDU
(PLCP frame) is reduced to 750 bytes...and accordingly, 726B of MAC MPDU, so
692 of MSDU and removing SNAP,  684Bytes effective for L3+ packets. That is
small I have to admit...even for CAMs/DENMs.

---
So, as MTU to the draft, we could follow three approaches, which strongly
depend on how sensitive IPv6 would be with incorrect MTUs..: 

Solution A: easy one: take the 802.11 standard value...2304 Bytes...cannot
be wrong, but will not by any mean provide a 'true' mMTU that could be
useful to IPv6 in challenging conditions.

Solution B (the neutral way): take the mMTU required by IPv6 without any
further support from ITS-G5. Cannot be wrong as well, as lower than 2304,
but same as before, will not reflect the true transfer unit in challenging
vehicular communications.

Solution C: take the mMTU of IPv6 as threshold requirement for IPv6 packets
to be sent on ITS-G5 (stronger requirement than solution B), define a
maximum transmit duration (I mentioned 1ms, but maybe this is extreme..)
that ITS-G5/DSRC can allocate for each IPv6 packet and use this to configure
a mMTU for different modulations (and write it in the IETF draft, so it ends
up like a look-up table). For all MTU that are lower than the mMTU required
by IPv6, IPv6 'should' not be able to be transmitted on ITS-G5. 

What do you think?

Best Regards,

Jérôme