Subject: [lp-wan] overview issue#1: worst case MTU...

From: Stephen Farrell <[email-masked]>
Date: Sun, 14 May 2017 10:37:07 +0100

Hiya,

In [1], I note that I don't know what's the worst case MTU
that might apply in NB-IoT. Does anyone know? To be clear,
I'm asking what MTU would apply in the worst-case network
conditions where some LPWAN traffic can get through. (Though
there's probably a better way to ask the question:-)

Do the WG think that it'd be useful to have that for each
of the technologies covered? (I think it would, fwiw.)

Cheers,
S.

[1] https://tools.ietf.org/html/draft-ietf-lpwan-overview-02#section-2.2.2

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Mon, 15 May 2017 09:07:33 +0200

Hi Stephen,

> of the technologies covered? (I think it would, fwiw.)

It is really useful (and actually required for IPv6 over LPWAN) to have
such information for each covered technology.

I think such information is already included in the document for LoRaWAN
and SIGFOX. So whether 1600 bytes is the worst-case MTU in NB-IoT should
be confirmed, and the worst-case MTU for Wi-SUN should also (ideally) be
explicitly stated.

It would also be very useful to have information on uplink and downlink
message rate (i.e. message per time unit) constraints beyond those
naturally due to the physical layer bit rate, for all technologies
covered.

Cheers,

Carles

---

From: Antti Ratilainen <[email-masked]>
Date: Mon, 15 May 2017 12:19:00 +0000

Dear all,

I'm not quite sure what is meant by worst case MTU. But in the case of NB-IoT, any size packet up to the said MTU size (1600 bytes) can be passed to NB-IoT from higher layers, segmentation of the packet is performed in the RLC layer, which can segment the data to transmission blocks with size as small as 16 bits. Hope this clarifies this issue for NB-IoT.

I have also informed Stephen with this answer along with some other updates regarding NB-IoT section of the overview document.

Best regards,
Antti

-----Original Message-----
From: lp-wan [mailto:[email-masked]] On Behalf Of Carles Gomez Montenegro
Sent: 15. toukokuuta 2017 10:08
To: Stephen Farrell <[email-masked]>
Cc: lp-wan <[email-masked]>
Subject: Re: [lp-wan] overview issue#1: worst case MTU...

Hi Stephen,

> Do the WG think that it'd be useful to have that for each of the 
> technologies covered? (I think it would, fwiw.)

It is really useful (and actually required for IPv6 over LPWAN) to have such information for each covered technology.

I think such information is already included in the document for LoRaWAN and SIGFOX. So whether 1600 bytes is the worst-case MTU in NB-IoT should be confirmed, and the worst-case MTU for Wi-SUN should also (ideally) be explicitly stated.

It would also be very useful to have information on uplink and downlink message rate (i.e. message per time unit) constraints beyond those naturally due to the physical layer bit rate, for all technologies covered.

Cheers,

Carles

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

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 15 May 2017 13:22:23 +0100

On 15/05/17 13:19, Antti Ratilainen wrote:
> Dear all,
> 
> I'm not quite sure what is meant by worst case MTU. But in the case
> of NB-IoT, any size packet up to the said MTU size (1600 bytes) can
> be passed to NB-IoT from higher layers, segmentation of the packet is
> performed in the RLC layer, which can segment the data to
> transmission blocks with size as small as 16 bits. Hope this
> clarifies this issue for NB-IoT.

Ah, ok, so 1600 is always ok for an IP layer on top of NB-IoT then,
even if it'd not perform as well maybe in lossy conditions - is that
right?

> 
> I have also informed Stephen with this answer along with some other
> updates regarding NB-IoT section of the overview document.

Please do check that I've gotten those into the latest version. If
not, (first: sorry:-) and just send me a pointer to the mail and
I'll shoot out a -03 if stuff still needs fixing

Cheers,
S.

> 
> Best regards, Antti
> 
> -----Original Message----- From: lp-wan
> [mailto:[email-masked]] On Behalf Of Carles Gomez
> Montenegro Sent: 15. toukokuuta 2017 10:08 To: Stephen Farrell
> <[email-masked]> Cc: lp-wan <[email-masked]> Subject: Re:
> [lp-wan] overview issue#1: worst case MTU...
> 
> Hi Stephen,
> 
> It is really useful (and actually required for IPv6 over LPWAN) to
> have such information for each covered technology.
> 
> I think such information is already included in the document for
> LoRaWAN and SIGFOX. So whether 1600 bytes is the worst-case MTU in
> NB-IoT should be confirmed, and the worst-case MTU for Wi-SUN should
> also (ideally) be explicitly stated.
> 
> It would also be very useful to have information on uplink and
> downlink message rate (i.e. message per time unit) constraints beyond
> those naturally due to the physical layer bit rate, for all
> technologies covered.
> 
> Cheers,
> 
> Carles
> 
> _______________________________________________ lp-wan mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/lp-wan
>

---

From: Antti Ratilainen <[email-masked]>
Date: Mon, 15 May 2017 12:43:46 +0000

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: 15. toukokuuta 2017 15:22
To: Antti Ratilainen <[email-masked]>; Carles Gomez Montenegro <[email-masked]>
Cc: lp-wan <[email-masked]>
Subject: Re: [lp-wan] overview issue#1: worst case MTU...

On 15/05/17 13:19, Antti Ratilainen wrote:
> Dear all,
> 
> I'm not quite sure what is meant by worst case MTU. But in the case of 
> NB-IoT, any size packet up to the said MTU size (1600 bytes) can be 
> passed to NB-IoT from higher layers, segmentation of the packet is 
> performed in the RLC layer, which can segment the data to transmission 
> blocks with size as small as 16 bits. Hope this clarifies this issue 
> for NB-IoT.

Ah, ok, so 1600 is always ok for an IP layer on top of NB-IoT then, even if it'd not perform as well maybe in lossy conditions - is that right?

[Antti] To clarify, the 1600 B MTU is based on 1500 B IP layer packet + some overhead. The packet provided from higher layer does not have to be that large, it can be smaller as well.
And yes, RLC layer may take the radio conditions of the channel into account when performing the segmentation of the IP layer packet, using lower size transmission blocks and better MCS to counter the bad radio connection. Of course with 1600 B  packet segmented into such small transmission blocks in bad radio conditions, it will take relatively long time to transmit the whole packet.

> updates regarding NB-IoT section of the overview document.

Please do check that I've gotten those into the latest version. If not, (first: sorry:-) and just send me a pointer to the mail and I'll shoot out a -03 if stuff still needs fixing

[Antti] I will send updates as per your request.

Cheers,
S.

> [mailto:[email-masked]] On Behalf Of Carles Gomez Montenegro 
> Sent: 15. toukokuuta 2017 10:08 To: Stephen Farrell

---

From: Juan Carlos Zuniga <[email-masked]>
Date: Mon, 15 May 2017 12:45:06 +0000

Hi Antti,

> 
> I'm not quite sure what is meant by worst case MTU. But in the case of NB-IoT,
> any size packet up to the said MTU size (1600 bytes) can be passed to NB-IoT
> from higher layers, segmentation of the packet is performed in the RLC layer,
> which can segment the data to transmission blocks with size as small as 16 bits.
> Hope this clarifies this issue for NB-IoT.

Is this true for both IP data mode as well as non-IP data over NAS (using the SCEF)?

Best,

Juan Carlos

---

From: Antti Ratilainen <[email-masked]>
Date: Tue, 16 May 2017 06:13:54 +0000

Hi Juan Carlos,

Yes, it is true for both cases.

Best regards,
Antti

-----Original Message-----
From: Juan Carlos Zuniga [mailto:[email-masked]] 
Sent: 15. toukokuuta 2017 15:45
To: Antti Ratilainen <[email-masked]>; Carles Gomez Montenegro <[email-masked]>; Stephen Farrell <[email-masked]>
Cc: lp-wan <[email-masked]>
Subject: RE: [lp-wan] overview issue#1: worst case MTU...

Hi Antti,

> performed in the RLC layer, which can segment the data to transmission blocks with size as small as 16 bits.

Best,

Juan Carlos