Subject: [lp-wan] re-order header field request

From: Arun <[email-masked]>
Date: Mon, 19 Jun 2017 12:38:15 +0200

Hi all,
Absence of window bit in the last fragment of the packet makes it tricky
to unmarshall the header at the receiver.
As I see it, the receiver up front shall know the length of the CFN
field depending on the Window size configured but doesn't know to
anticipate the last fragment unless indicated by CFN.
So I think,  we need to maintain same order on all fragment headers.

existing;

      		<------------ R ---------->
                          <--T--> 1 <--N-->
               +-- ... --+- ... -+-+- ... -+
               | Rule ID | DTag  |W|  CFN  |
               +-- ... --+- ... -+-+- ... -+

shall be;
     		<------------ R ---------->
                          <--T--> <--N--> 1
               +-- ... --+- ... -+- ... -+-+
               | Rule ID | DTag  |  CFN  |W|
               +-- ... --+- ... -+- ... -+-+

and for the last fragment
   		<------------ R ---------->
                          <--T--> <--N--> 
               +-- ... --+- ... -+- ... -+-+
               | Rule ID | DTag  |  CFN  |MIC
               +-- ... --+- ... -+- ... -+-+

what do you think?

thanks,
Arun

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Tue, 20 Jun 2017 18:01:27 +0200

Hi Arun,

Thanks for pointing this out.

Your proposal seems fine to me, except for the (possibly minor) detail
that in your proposal "R" would comprise a number of header fields for the
last fragment that would be different from the number of fields in
previous fragments.

Maybe we could also consider another solution: adding the W bit in the
header of the last fragment of the packet.

I haven't found examples of scenarios where the W bit is actually needed
in the last fragment (i.e. fragment with "all ones" CFN). However, I'm
wondering if there is an actual benefit or a related use case that may
require *not* having a W bit in the last fragment header. (If anyone has
any in mind, please chime in!)

On the other hand, if we have the W bit also in the last fragment header,
header format will be more uniform across all fragments.

Thoughts?

Cheers,

Carles

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

---

From: "weigengyu" <[email-masked]>
Date: Wed, 21 Jun 2017 10:01:03 +0800

Hi,

There is a question about Format in 
draft-ietf-lpwan-ipv6-static-context-hc-04.

>       <------------ R ---------->

Why each successive fragment must contain a Rule ID?

It is known that the DTag is used as an indication of fragments belonged to 
the same IPv6 packet.
A Rule ID in the first fragement can be passed to the receiver how to do HC 
compression,
but the successive fragments containing a Rule ID just send a redundent 
information to the receiver.
Right?

Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
-----原始邮件----- 
From: Carles Gomez Montenegro
Sent: Wednesday, June 21, 2017 12:01 AM
To: Arun
Cc: lp-wan ; Laurent Toutain ; Ana Minaburo
Subject: Re: [lp-wan] re-order header field request

Hi Arun,

Thoughts?

Cheers,

Carles

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Wed, 21 Jun 2017 08:13:11 +0200

Hi Gengyu,

> information to the receiver.

The Rule ID is needed to provide a receiver with information on what type
of content is being carried (and how it has to be handled). Note that not
all IPv6 packets will require fragmentation, and then losses may happen,
also non-fragmented packets may be interleaved with fragments, etc.

Cheers,

Carles

---

From: Arun <[email-masked]>
Date: Wed, 21 Jun 2017 09:47:22 +0200

Hi Carles,

 Having the uniform header format seems to be an ideal solution but
Tx'ing additional bit without any significance seems contentious.
Will wait for more feedbacks or comments :)

thanks,
Arun

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Wed, 21 Jun 2017 10:02:17 +0200

Hi Arun,

The point here is that the Rule ID field in fragments except the last one
will not use the W bit (or equivalently, have one bit less than the Rule
ID field in the last fragment as per current formats).

So I'm wondering if this "additional bit" in the Rule ID of the last
fragment could have any useful purpose or not, or conversely would just
complicate the structure and uniformity of fragmentation headers.

Thoughts?

Cheers,

Carles

---

From: Laurent Toutain <[email-masked]>
Date: Wed, 21 Jun 2017 10:09:12 +0200

Hi,

I don't think it is a problem to keep it, in a All 1 Frag, even if we don't
use it (MIC is out of window numbering).  we have alignment on bytes when
we send a message, so the benefit is not obvious if we don't keep it.

But in  ACK message the W bit must be present.

Laurent

---

From: Arun <[email-masked]>
Date: Wed, 21 Jun 2017 11:23:47 +0200

Hi Carles,
IMO, Rule ID would be a separate entity from other fields and will not
consume Wbit.

thanks,
Arun

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Wed, 21 Jun 2017 11:55:25 +0200

Hi Laurent,

> we send a message, so the benefit is not obvious if we don't keep it.

Thanks for your comment.

> But in  ACK message the W bit must be present.

Yes, this is covered by the new feature in -04 whereby all ACKs carry a   
 W bit, which indicates the window being acknowledged.

Cheers,

Carles

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Wed, 21 Jun 2017 11:59:11 +0200

Hi Arun,

Yes, actually it is the other way round: the W bit is consuming 1 bit out of
R bits (the latter defines the size of something we could call the
'original Rule ID space').

Thanks,

Carles

---

From: "weigengyu" <[email-masked]>
Date: Wed, 21 Jun 2017 22:51:52 +0800

Hi,

> Note that not all IPv6 packets will require fragmentation,
> and then losses may happen,

It seems that there may not apply two rules for one IP packets.
Or all fragments belonged to one pakcet should have the same Rule ID and the 
Dtag.

If one fragment is lost, the packet can not be assembled.
The packet will be assembled only after all fragments received correctly.

Fragments belonged to different packets will be assigned with different 
Dtags.

Anything wrong?

Regards,

Gengyu WEI
-----原始邮件----- 
From: Carles Gomez Montenegro
Sent: Wednesday, June 21, 2017 2:13 PM
To: weigengyu
Cc: lp-wan ; Arun ; Ana Minaburo ; Laurent Toutain
Subject: Re: [lp-wan] re-order header field request

Hi Gengyu,

Cheers,

Carles