Subject: [6lowpan] closing on update to HC draft

From: Geoff Mulligan <[email-masked]>
Date: Wed, 03 Mar 2010 16:00:00 -0700

>From what I can tell we appear to be closing in on the idea (from Daniel
plus others) that the HC draft should only:
  - Allocate a new dispatch value for the "changed" frag offset and
length value
  - Define the frag offset and length to be the values relevant for the
actual data in the packet (compresses or not)
  - Strongly deprecate the old frag dispatch value

  Agree or disagree?

	geoff

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 4 Mar 2010 00:19:07 +0100

>  - Strongly deprecate the old frag dispatch value

I personally believe 4944's fragmentation is fine.
I must have missed a lot of discussion if the above is the resolution.

Gruesse, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 4 Mar 2010 08:04:27 +0100

Hi:

I do not think that the current fragmentation is fine. We have a number
of issues that deserve attention IMHO::
- How to forward fragments in route over
- fragment loss and recovery,
- datagram size determination in the presence of unknown compressed
headers over multiple fragments
- impacts on sniffers, debugability.

So while I'd agree that 4944 is self-sufficient for one hop
applications, I think there's a need for a serious second pass on
fragmentation.
The group as voted that in the past and we've not acted for charter
reasons. Does not mean we can never make it.

Also:
I think that the proposed resolution below is at best a temporary patch.
For all I know, we are not chartered to make it, and if we are, then we
should address the whole problem.

And BTW:
This is NOT an HC problem. My reading from the last call thread is that
we could add words in HC to limit the compression to the first fragment
if RFC 4944 is used there, but that's about it.

Cheers,

Pascal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Carsten Bormann
> Sent: Thursday, March 04, 2010 12:19 AM
> To: Geoff Mulligan
> Cc: 6lowpan
> Subject: Re: [6lowpan] closing on update to HC draft
> 
> 
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan

---

From: Geoff Mulligan <[email-masked]>
Date: Thu, 04 Mar 2010 00:28:54 -0700

Carsten,
  You did indicate in a message that you thought that 4944 was fine as
it was as it does NOT say that you can compress anything that is not in
the first fragment.

My listening to the discussion seemed to be that folks didn't think that
this was sufficient.  I also don't think that it is sufficient.

We could explicitly state, for clarity, that you MUST NOT compress
anything outside the first fragment, but then what happens if someone
decides to use RPL or some other source routed protocol that inserts a
routing extension header or some other extension header that "pushes" a
compressed header into the second fragment.  Would the node have to
uncompress that header?

If that is not a problem, then maybe we can just state that thou MUST
NOT compress outside fragment 1.

If it is a problem, then this seems like a good fix.

	geoff

---

From: "Anders Brandt" <[email-masked]>
Date: Thu, 4 Mar 2010 08:55:18 +0100

> >From what I can tell we appear to be closing in on the idea (from 
> >Daniel plus others

Agree.

Pascal may be right that there are other nice things we could consider
if we open all boxes again but this is a sufficient "metal fix" (in ASIC
design terminology) to resolve the current issue.

It solves an existing, real problem. It allows RPL to run long headers
(more than one fragment) and it does not
(seem to) introduce new problems.

- Anders

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Geoff Mulligan
> Sent: Thursday, March 04, 2010 00:00
> To: 6lowpan
> Subject: [6lowpan] closing on update to HC draft
> 
>   - Allocate a new dispatch value for the "changed" frag 
> offset and length value
>   - Define the frag offset and length to be the values 
> relevant for the actual data in the packet (compresses or not)

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 4 Mar 2010 10:36:58 +0100

Hi Anders:

If RPL effectively needs the patch, I'll be more than willing to make it
urgently.
I think you have in mind a long string of routing headers, correct?
 If so, do you have a concrete reason to believe that people would do
that rather than maintain some intermediate states?

Pascal

> Behalf Of Anders Brandt
> Sent: Thursday, March 04, 2010 8:55 AM
> To: Geoff Mulligan; 6lowpan
if we
> open all boxes again but this is a sufficient "metal fix" (in ASIC
design
> terminology) to resolve the current issue.
> 
(more
> than one fragment) and it does not (seem to) introduce new problems.
> 
> - Anders
> 
> > >Daniel
> >   - Define the frag offset and length to be the values relevant for
> > the actual data in the packet (compresses or not)

---

From: "Anders Brandt" <[email-masked]>
Date: Thu, 4 Mar 2010 10:55:39 +0100

Hi Pascal

The support for a potential long RPL header is just a special case.
Other PHY/MAC technologies may have shorter frames than 128 bytes.
Add L2 security and you may have an issue even before.

The main point is the two other issues:
* Fragment offsets affected by header compression
* Fix does not (seem to) introduce new problems.

This small clarification let us work in a normal layered fashion:
1) Compress the header if you feel like. Or do not - the choice is
yours.
2) Transmit the datagram - compressed or not.
  a) Use fragmentation if you have to. Offsets allow reassembly.
3) Load fragments in receive buffer. Option: Start at an offset into
   the buffer so that you do not have to memcpy the IP payload.
4) Decompress header.
5) Deliver to IP stack.

This seems very simple and obvius to me. Where is the problem?

- Anders

> From: Pascal Thubert (pthubert) [mailto:[email-masked]] 
> Sent: Thursday, March 04, 2010 10:37
> To: Anders Brandt; Geoff Mulligan; 6lowpan
> Subject: RE: [6lowpan] closing on update to HC draft
> 
> Hi Anders:
> 
> If RPL effectively needs the patch, I'll be more than willing 
> to make it urgently.
>  If so, do you have a concrete reason to believe that people 
> would do that rather than maintain some intermediate states?
> 
> Pascal
> 
> 
> offset and 
> relevant for

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 4 Mar 2010 13:09:11 +0100

> anything outside the first fragment,

That is a nice editorial clarification.
I'm in favor of adding that.

> but then what happens if someone
> compressed header into the second fragment.  

I'd say: Since you can't do that, don't do that.

Also, I'd say we shouldn't try to use HC for RPL headers.
Instead, we should design RPL headers to be sane in the first place.
I have no idea where the notion came from that RPL must do something dumb and then HC needs to mop up after it.
(I also don't understand why these headers must be so large that they require every packet to be L2-fragmented.
It's not like RPL is a general Internet protocol; it's meant for LLNs, which all react adversely to giant overheads.)

> NOT compress outside fragment 1.

This is what I thought we were converging on?

Gruesse, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 4 Mar 2010 13:21:32 +0100

> This is what I thought we were converging on?
[Pascal] Agreed, as long as the restriction applies to the existing
fragmentation (4944). We cannot presume that this restriction will still
be required for upcoming methods.
It will be up to those new methods to specify whether they need that
restriction or not.

Pascal

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 4 Mar 2010 13:26:46 +0100

Anders,

the issue is that we are not in a green field position here.
6lowpan already has a fragmentation scheme that I maintain works well.

Indeed, 6lowpan fragmentation does not address:
-- per-L2-hop ACKs on fragments (what Pascal's draft is about)
-- compressed headers outside of the first fragment (only the first fragment has a dispatch).

On the other hand, if you don't need either, the somewhat weird layering of 6lowpan's fragmentation is a better fit to constrained nodes than a more strict (fragment-the-compressed-PDU) layering.

> Other PHY/MAC technologies may have shorter frames than 128 bytes.

Ah, but that wouldn't be 6lowpan, or would it?
Tell us more about the use case.
(For smaller cell-sizes, fragmentation may not be the right model; there was more than one reason that IPv4 had a minimum MTU of 68 bytes.  See RFC3819)

> Add L2 security and you may have an issue even before.

I'd still like to see the use case.
The about 70 bytes of L2 payload you get for maximum security in 6lowpan is fine for just about any compressed(!) header.
If RPL stuff is larger than that (oh my), just don't try to compress it in HC.
(On the contrary, I think that the ability to independently decompress/recompress HC per-fragment is a *major* win.)

> * Fragment offsets affected by header compression

Doesn't happen in 6lowpan header compression.
(What does happen is that more than a fragment's size logically fits into the first fragment, but that is kind of inevitable in compression.)

> * Fix does not (seem to) introduce new problems.

1) I haven't seen the fix.  Do we have text to look at?
2) The one obvious new problem would be to invalidate existing implementations.

>   the buffer so that you do not have to memcpy the IP payload.

In this scheme, you don't have that option if the fragments arrive out of order.
With 6lowpan's fragmentation, you get the correct offset for free.  That was the idea.
But it only works very well if you don't try to compress non-initial fragments.

Sorry to cause pain here.
Fragmentation is probably the most boring subject on earth.
It is still hard to get right.

Gruesse, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 4 Mar 2010 13:29:02 +0100

> It will be up to those new methods to specify whether they need that

Absolutely!
I was trying to talk about 4944 fragmentation.

(But then, again, I believe that the ability to independently decompress/recompress headers in single fragments is a major win that other fragmenters might want to benefit from.)

Gruesse, Carsten

---

From: Daniel Gavelle <[email-masked]>
Date: Thu, 04 Mar 2010 12:33:55 +0000

I would be happy to close on the HC-06 with a note saying that 
compression doesn't extend past the first fragment.

The main issue that I can see causing fragments to be pushed into 
subsequent fragments is not with the ROLL packets but with any packets 
that are source routed and use the IPv6 routing extension header (sect 
4.4 of rfc2460).

For example, if ROLL is used with the DAG information held only on the 
edge router and routers within the wireless network rely on source 
routing inserted at the edge router, the routing extension headers would 
be before the UDP header and may push the UDP header into the next 
fragment.

However, this problem could be addressed with a later RFC which 
addresses both fragmentation and addresses compression of the routing 
extension header.  We don't need to hold up the progress of the HC-06 
draft to resolve this issue.

Off topic, I do think that the HC-06 header compression would be good to 
use with the ROLL addresses.  This would allow the same software and 
context information to be re-used, rather than inventing a new IPv6 
address compression scheme for ROLL.

Daniel.

-- 
__________________________________________________
Daniel Gavelle, Software Engineer
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
Comp Reg No: 3191371  Registered In England
http://www.jennic.com
__________________________________________________

---

From: "Anders Brandt" <[email-masked]>
Date: Thu, 4 Mar 2010 13:39:17 +0100

Hi Carsten

(sorry - sort of off-topic)

> -- per-L2-hop ACKs on fragments

I assume 6lowPan is intended for shared media?
In such environments it is waste of good bandwith to send L2 Acks
for messages that are going to be forwarded anyway. You can hear
the forwarded message just as well as the ack.....
Yes, I know: "Layer violation" - but come on!
Saving 50% bandwidth can justify quite a bit ;-)

This is just to say that maybe fragment Ack'ing needs some more
work before we can close that one....

- Anders

> [mailto:[email-masked]] On Behalf Of Carsten Bormann
> Sent: Thursday, March 04, 2010 13:27
> To: Anders Brandt
> Cc: 6lowpan
> On the other hand, if you don't need either, the somewhat 
> weird layering of 6lowpan's fragmentation is a better fit to 
> constrained nodes than a more strict 
> (fragment-the-compressed-PDU) layering.
> 
> (For smaller cell-sizes, fragmentation may not be the right 
> model; there was more than one reason that IPv4 had a minimum 
> MTU of 68 bytes.  See RFC3819)
> 
> The about 70 bytes of L2 payload you get for maximum security 
> in 6lowpan is fine for just about any compressed(!) header.
> (On the contrary, I think that the ability to independently 
> decompress/recompress HC per-fragment is a *major* win.)
> 
> (What does happen is that more than a fragment's size 
> logically fits into the first fragment, but that is kind of 
> inevitable in compression.)
>

---

From: "Anders Brandt" <[email-masked]>
Date: Thu, 4 Mar 2010 13:43:33 +0100

Hi Carsten

> But it only works very well if you don't try to compress 

Out-of-order reception should be recoverable with the proposed fix.
After all we are just talking about a (different) constant offset
to the rest of the fragments?

- Anders

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 4 Mar 2010 13:50:49 +0100

Hi Anders

Yes, I suspect that hearing promiscuously your packet being repeated can
be considered an ack in a mesh under network, but that's not the point
that the draft addresses - that is  a mesh under problem to be solved by
the mesh under technology. In route over, you never know what the next
hop technology will be.

And what the draft Jonathan and I put together for fragments is a
sublayer below the fragmentation, acting end to end over a LoWPAN.
That's useful as soon as you carry the packets over multiple hops, which
is natural in mesh under but hopefully will be generalized to route
over, using the datagram tag as a label to route subsequent fragment
along the path selected for the first fragment. 

Cheers,

Pascal

> Sent: Thursday, March 04, 2010 1:39 PM
> To: Carsten Bormann
> Cc: 6lowpan
> In such environments it is waste of good bandwith to send L2 Acks for
> messages that are going to be forwarded anyway. You can hear the
> forwarded message just as well as the ack.....
> This is just to say that maybe fragment Ack'ing needs some more work
> before we can close that one....
> 
> - Anders
> 
> > On the other hand, if you don't need either, the somewhat weird
> > layering of 6lowpan's fragmentation is a better fit to constrained
> > nodes than a more strict
> > (For smaller cell-sizes, fragmentation may not be the right model;
> > there was more than one reason that IPv4 had a minimum MTU of 68
> > bytes.  See RFC3819)
> >
> > The about 70 bytes of L2 payload you get for maximum security in
> > 6lowpan is fine for just about any compressed(!) header.
> > (What does happen is that more than a fragment's size logically fits
> > into the first fragment, but that is kind of inevitable in
> > compression.)
> >
> > In this scheme, you don't have that option if the fragments arrive
out
> > of order.

---

From: Zach Shelby <[email-masked]>
Date: Thu, 4 Mar 2010 20:47:56 +0200

> I'm in favor of adding that.

Yep, this is the minimum required. 

Now we seem to be split on whether we need more than this. Personally I can live with the above as this is clearly the fastest way to move this draft to the IESG, but I don't have problems with the fix suggested by Anders. How about we try to reach consensus by Friday afternoon, if we can't agree to agree, then we can always use this clarification. 

It would be sooo nice to have HC already to the IESG so we can concentrate on getting ND done in Anaheim ;-)

Zach 

-- 
http://www.sensinode.com
http://zachshelby.org - My blog "On the Internet of Things"
http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 5 Mar 2010 10:52:48 +0100

Hi Zach:

I do not mind working on Anders' suggestion at all. In fact I strongly
support working on fragments and his proposal is a great start.

I do not mind publishing a draft that just has Anders' proposal in it,
as long as we have a design and a clear roadmap for the rest of the
fragment work where that proposal would fit - as opposed to have to
deprecate it (again) 6 month from now.

What I think is that HC is not the right draft for that proposal. HC is
about Header Compression. We won't get anywhere if we keep changing the
scope or adding features to this draft - or any draft. 

Pascal

> Behalf Of Zach Shelby
> Sent: Thursday, March 04, 2010 7:48 PM
> To: [email-masked]
> Now we seem to be split on whether we need more than this. Personally
I
> can live with the above as this is clearly the fastest way to move
this draft to
> the IESG, but I don't have problems with the fix suggested by Anders.
How
> about we try to reach consensus by Friday afternoon, if we can't agree
to
> agree, then we can always use this clarification.
> 
> It would be sooo nice to have HC already to the IESG so we can
concentrate
> on getting ND done in Anaheim ;-)
> 
> Zach
> 
> --
> http://www.sensinode.com
> This e-mail and all attached material are confidential and may contain
legally
> privileged information. If you are not the intended recipient, please
contact
> the sender and delete the e-mail from your system without producing,
> distributing or retaining copies thereof.
> 
> 
> 
>

---

From: Zach Shelby <[email-masked]>
Date: Fri, 5 Mar 2010 13:47:37 +0200

Pascal,

Got you, makes perfect sense. So let's just go with the:

"We could explicitly state, for clarity, that you MUST NOT compress
>>>> anything outside the first fragment"

Anders - are you OK with doing further work in a separate fragmentation document? 

Zach

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

---

From: "Anders Brandt" <[email-masked]>
Date: Fri, 5 Mar 2010 13:31:23 +0100

Zach, Pascal,

> Anders - are you OK with doing further work in a separate 

Sure.

- Anders 

> [mailto:[email-masked]] On Behalf Of Zach Shelby
> Sent: Friday, March 05, 2010 12:48
> To: Pascal Thubert (pthubert)
> Cc: [email-masked]
> > What I think is that HC is not the right draft for that 
> proposal. HC 
> > is about Header Compression. We won't get anywhere if we 
> keep changing 
> > the scope or adding features to this draft - or any draft.
> > 
> > Pascal
> > 
> > 
> [mailto:[email-masked]] On 
> >> Behalf Of Zach Shelby
> This e-mail and all attached material are confidential and 
> may contain legally privileged information. If you are not 
> the intended recipient, please contact the sender and delete 
> the e-mail from your system without producing, distributing 
> or retaining copies thereof. 
> 
> 
> 
>

---

From: Jonathan Hui <[email-masked]>
Date: Fri, 5 Mar 2010 07:59:13 -0800

I'm fine with keeping any fragmentation fixes to a separate doc.  But  
if we do so, I'd prefer to first create a short draft that specifies  
the baseline features I outlined in a prior mail:

- Ability to ACK/NACK any 6lowpan packet (fragmented or not).
- Fragmentation makes no assumptions of the compression mechanism above.
- Ability to carry arbitrary payloads in ACK/NACK.
- Carry 6lowpan packet sequence number/tag separate from MAC.

With that, we can specify other features as needed (e.g. SACK, etc.)  
in separate drafts.

--
Jonathan Hui

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 5 Mar 2010 17:51:06 +0100

Hi Jonathan:

Unsure what you mean by "first". Does that relate to the fragment work
or is that linked to the HC work?
IOW do you agree with the plan to 1) move HC to IESG, and then 2) work
on fragments and all you listed below?

Pascal

> From: Jonathan Hui [mailto:[email-masked]]
> Sent: Friday, March 05, 2010 4:59 PM
> To: Anders Brandt
> Cc: Zach Shelby; Pascal Thubert (pthubert); [email-masked]
if we do
> so, I'd prefer to first create a short draft that specifies the
baseline features I
> outlined in a prior mail:
> 
in
> separate drafts.
> >> This e-mail and all attached material are confidential and may
> >> contain legally privileged information. If you are not the intended
> >> recipient, please contact the sender and delete the e-mail from
your
> >> system without producing, distributing or retaining copies thereof.
> >>
> >>
> >>
> >>

---

From: Jonathan Hui <[email-masked]>
Date: Fri, 5 Mar 2010 08:56:41 -0800

Hi Pascal,

I did not mean to link the two.  HC should go to IESG as quickly as  
possible.  I was merely trying to state my opinions on how to move  
forward with the fragment work, but only *after* we submit HC to  
IESG.  We presumably need to get the fragment work into a new charter  
item anyway before we can start work on that.

Sorry for the confusion.

--
Jonathan Hui

On Mar 5, 2010, at 8:51 AM, Pascal Thubert (pthubert) wrote:

>>>>>> contain

---

From: "Pete St. Pierre" <[email-masked]>
Date: Fri, 5 Mar 2010 09:50:06 -0800

> 
> I did not mean to link the two.  HC should go to IESG as quickly as possible.  I was merely trying to state my opinions on how to move forward with the fragment work, but only *after* we submit HC to IESG.  

Agreed.  I like the idea of getting HC done and through IESG without delay. I like where we are at.

> We presumably need to get the fragment work into a new charter item anyway before we can start work on that.

Agreed.

Congrats to everyone for getting to this point!
...Pete