Subject: [6lowpan] Fw: any comments on the proposal from Arch Rock

From: gabriel montenegro <[email-masked]>
Date: Sat, 4 Nov 2006 10:33:38 -0800 (PST)

Hi,

A few of us had a chance to look at this proposal earlier in the week. The message below
has comments from Carles Gomez, Mario Mao and myself.

Since it may be of interest to the group, I'm forwarding with permission from Carles and Mario.

-gabriel

----- Forwarded Message ----
From: Mario Mao <[email-masked]>
To: Carles Gomez <[email-masked]>; Geoff Mulligan <[email-masked]>
Cc: gabriel montenegro <[email-masked]>; Ki-Hyung Kim <[email-masked]>; Daniel Park <[email-masked]>; Carsten Bormann <[email-masked]>; Christian Schumacher <[email-masked]>
Sent: Friday, November 3, 2006 5:21:40 AM
Subject: Re: any comments on the proposal from Arch Rock

Hi All,

I would propose my opinions from the view of implementation, thanks.

First, I would say the new format is clear and supply more expansibility (just like IPv6 extension header).

For my concern, the multicast ability. For the most important reason of changing original byte-alignment format to current one is to add B bit and supply way of distinguishing seqno, how about that in new format? I don't see how does it work for this situation. Have I missed the critical point, thanks if author could give some hint.

About the hops left, I also agree the 15 hops would enough for most cases. In our environment, more than 10 hops would cause a surprising lag (beacon interval set to 1s). However, it is always right to save space for further development, we should figure out a good method to balance them.

At last, simple to implement. By our experience, new format may not bring convenience. We still have more than 3 headers/extensions to handle, equal to previous one (may more complex...). But the new format do bring benefits beyond that. For our tests show the original format affords enough ability for common IPv6 application over WSN, if the new one could follow the function exactly and not bring conflict, I vote for the hard packet format changing.

Regards,

Mario Mao
[email-masked]

----- Original Message ----- 
From: "Carles Gomez" <[email-masked]>
To: "Geoff Mulligan" <[email-masked]>
Cc: "gabriel montenegro" <[email-masked]>; "Ki-Hyung Kim" <[email-masked]>; "Daniel Park" <[email-masked]>; "Carsten Bormann" <[email-masked]>; "Christian Schumacher" <[email-masked]>; <[email-masked]>
Sent: Friday, November 03, 2006 6:47 PM
Subject: Re: any comments on the proposal from Arch Rock

> Dear all,
> 
> We believe the proposed new format is clearer and allows development of 
> extensions and addition of new options in an easier way, which is relevant 
> from the point of view of implementation.
> 
> In general, the new format allows for byte savings in most cases. However, 
> just to keep a fair comparison (it seems like the slides try to represent the 
> most favorable case for ArchRock proposal) it must be noted that when 
> fragmentation is needed, an offset field with a size equal to one byte must be 
> added to fragments other than the first one. Hence, in some cases as in slide 
> 9, "Multihop > 14 hops", 7 bytes would be needed with the new format for 
> fragments other than the first one, which is one byte more than that needed 
> with the current 6lowpan proposal. Anyway, the overall result seems to be a 
> clearer format with roughly the same size (in some cases smaller, in some 
> others the same as, and in some others greater than that of the current 
> 6lowpan proposal).
> 
> Regarding the number of hops, I agree that 15 hops should be enough in most 
> cases. 
> 
> Best regards,
> 
> Carles Gomez
> Technical University of Catalonia
> 
> Quoting Geoff Mulligan <[email-masked]>:
> 
> > Gabriel,
> >   Thanks for the quick review.  I think that David and Jonathan had the
> > same idea about using all ones as a mechanism to allow other proto
> > types.
> > 
> > I agree that the idea of 256 hops is probably overkill, i think that
> > some folks might think 15 hops is too small, but I think probably
> > appropriate for 90% of applications.
> > 
> > Also thanks for include Carlos.
> > 
> > Everyone, please weigh-in on this quickly.
> > 
> > geoff
> > 
> > On Thu, 2006-11-02 at 23:51 -0800, gabriel montenegro wrote:
> > > [I took the liberty of forwarding the slides and the email thread to
> > > the folks at
> > > Universidad Politecnica de Catalunya as they have also been involved
> > > in implementation
> > > work and would have valuable input. I'm cc-ing Carles to include them
> > > in the loop.]
> > >  
> > > Folks,
> > >  
> > > I have just now looked at the slides, and my first impression is that
> > > the format looks quite
> > > nice and definitely worth sending out to the list. One minor detail is
> > > that the dispatch
> > > field is smaller than the current prot_type, but we could just reserve
> > > the value
> > > of all 1's and use that to signal a subsequent extended dispatch field
> > > (like we used
> > > to have, and like they've done with hops). 
> > >  
> > > Slides 9 and 10 illustrate the potential gains. I don't think the
> > > large hop functionality
> > > is very real (the packet drop rate will probably make such long paths
> > > pointless). The
> > > extensibility, I think we already have (just define more protocol_type
> > > values). What I
> > > see in the fourth packet figure in slide 12 is more akin to
> > > "piggybacking". This is also
> > > possible in IPv6, of course, but is not always a good idea as it can
> > > get complex real soon.
> > > But having the chance of doing piggybacking (several protocols within
> > > one packet) could be
> > > useful, yes. In summary, I'm more cautious about jumping into
> > > piggybacking or deep-hopping
> > > than I am about the stacking approach itself.
> > >  
> > > Other than that, I'd really like to defer to the folks who've engaged
> > > in implementation
> > > of the current format draft.
> > > 
> > > -gabriel

_______________________________________________
6lowpan mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/6lowpan

---

From: Jonathan Hui <[email-masked]>
Date: Sat, 04 Nov 2006 11:15:35 -0800

In response to Mario's concerns about the B-bit for multicast meshing, 
we would argue that this functionality can be fairly represented by 
assigning a new dispatch type to creating a new extension header. This 
header does require two bytes (1 for the dispatch and 1 for the sequence 
number) vs. 1 extra byte in the current proposal. However, it is not 
clear to us whether an 8-bit sequence number field is sufficient for 
current and possibly future protocols that may implement multicast 
meshing. What the dispatch byte allows is support for not only a header 
that includes a single 8-bit sequence number, but also room for other 
future headers that may require more than that. We feel that adding the 
extra dispatch byte to allow support for multiple protocols is well 
worth it. Note that adding new extension headers is useful for any 
meshing protocol (both unicast and multicast).

In response to Carles' concerns about the byte counts, we believe we are 
doing the comparison fairly. In the case with fragmentation, you are 
correct that the offset byte must be added. However, the upper-layer 
protocol dispatch byte is only needed in the first fragment. This is 
analogous to the current 6lowpan format replacing the prot_type bits 
with the dgram_offset bits. However, we feel that our proposal is 
conceptually cleaner because the concepts of prot_type and dgram_offset 
are kept separate in orthogonal headers. Our fault for not making that 
clear in the slides, thanks for pointing that out.

--
Jonathan Hui
[email-masked]

gabriel montenegro wrote:
> Cc: gabriel montenegro <[email-masked]>; Ki-Hyung Kim 
> <[email-masked]>; Daniel Park <[email-masked]>; Carsten 
> Bormann <[email-masked]>; Christian Schumacher <[email-masked]>
> For my concern, the multicast ability. For the most important reason of 
> changing original byte-alignment format to current one is to add B bit 
> and supply way of distinguishing seqno, how about that in new format? I 
> don't see how does it work for this situation. Have I missed the 
> critical point, thanks if author could give some hint.
> 
> About the hops left, I also agree the 15 hops would enough for most 
> cases. In our environment, more than 10 hops would cause a surprising 
> lag (beacon interval set to 1s). However, it is always right to save 
> space for further development, we should figure out a good method to 
> balance them.
> 
> At last, simple to implement. By our experience, new format may not 
> bring convenience. We still have more than 3 headers/extensions to 
> handle, equal to previous one (may more complex...). But the new format 
> do bring benefits beyond that. For our tests show the original format 
> affords enough ability for common IPv6 application over WSN, if the new 
> one could follow the function exactly and not bring conflict, I vote for 
> the hard packet format changing.
> 
> Regards,
> 
> Mario Mao
> [email-masked]
> 
> 
> Cc: "gabriel montenegro" <[email-masked]>; "Ki-Hyung 
> Kim" <[email-masked]>; "Daniel Park" <[email-masked]>; 
> "Carsten Bormann" <[email-masked]>; "Christian Schumacher" 
> <[email-masked]>; <[email-masked]>
> ------------------------------------------------------------------------
>

---

From: Jonathan Hui <[email-masked]>
Date: Sat, 04 Nov 2006 12:07:01 -0800

Hi Gabriel, thanks for your feedback as well.

In the current 6lowpan proposal, the prot_type field disappears in 
packets that are subsequent fragments. Thus, the prot_type field in the 
current proposal only allows extensibility in upper layer protocols and 
possibly in packets that do not require fragmentation. In the current 
6lowpan proposal it wasn't clear to us how a new mesh protocol that 
wanted to add a field to the header would do so in a clean way. Also, 
what we were trying to convey with the "piggybacking" capability with 
the stacked headers was that it was possible, not that we should promote 
it.

Overall, what we are trying to promote is a header format that is 
extensible and flexible so that we can cleanly adapt when new ideas or 
unforeseen issues arise in the future. This also applies with the hops 
extension for deep mesh networks.

A few people have already mentioned that 15 hops is fine in most cases. 
But we wanted show that we could support essentially all of the current 
functionality in the 6lowpan proposal (which includes support for >15 
hops) rather than showing reduced functionality.

--
Jonathan Hui
[email-masked]