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 PROTECTED]>
To: Carles Gomez <[EMAIL PROTECTED]>; Geoff Mulligan <[EMAIL PROTECTED]>
Cc: gabriel montenegro <[EMAIL PROTECTED]>; Ki-Hyung Kim
<[EMAIL PROTECTED]>; Daniel Park <[EMAIL PROTECTED]>; Carsten
Bormann <[EMAIL PROTECTED]>; Christian Schumacher <[EMAIL PROTECTED]>
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 PROTECTED]
----- Original Message -----
From: "Carles Gomez" <[EMAIL PROTECTED]>
To: "Geoff Mulligan" <[EMAIL PROTECTED]>
Cc: "gabriel montenegro" <[EMAIL PROTECTED]>; "Ki-Hyung
Kim" <[EMAIL PROTECTED]>; "Daniel Park" <[EMAIL PROTECTED]>;
"Carsten Bormann" <[EMAIL PROTECTED]>; "Christian Schumacher"
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
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 PROTECTED]>:
>
> > 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 protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
