Subject: RE: Summary Re: [nemo] comments on "Tree Discovery" draft

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Mon, 30 Aug 2004 17:05:17 +0200

> > The CRC method allows each visitor to keep and independent state for
> >  its view of the path out of the nested tree. For that purpose, the
> > crc32c is arguably as good as the string of careofs.
> 
> Yes, and it is also as good as the rfc2460 checksum and as the simple
> XOR'ing of the EUID's.  Why CRC32c?
RFC 2460 does not define the checksum, but the pseudo header. If there's
still legacy ICMP, TCP and UDP above, then it will be a 16bit checksum,
which is not exactly 'as good' as 32 bits CRC.

We now have a standard, readily available, for a robust 32 bits
function. For our purpose, it is needed only on RA-TIO which is not like
on every packet. And we can afford the 32bits in the TIO. So, why not
CRC32C? 

> 
> > Since that view might be echoed in the RO states at the HA, it is
> > important not to miss changes.
> 
> You seem to have a relatively clear picture of a certain RO mechanism,
> by assumption.  Is this RRH by any chance?
> 
RRH was there before NEMO was a working group. Since then, RRH has given
us some good practise of Route Optimization. And yes, we found that this
was a very relevant information. Other drafts were published for which
the path was known by the HA, like draft-na-nemo-nested-path-info-00. TD
does not imply RRH. TD provides a set of valuable information that RO
can build on. The TD draft is still 00. We can discuss about adding new
fields, for instance as optional suboptions - I hope we do it, actually.

Pascal

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 30 Aug 2004 18:25:41 +0200

Pascal Thubert (pthubert) wrote:
>>> The CRC method allows each visitor to keep and independent state
>>>  for its view of the path out of the nested tree. For that 
>>> purpose, the crc32c is arguably as good as the string of careofs.
>>> 
>>> 
>>> 
>> Yes, and it is also as good as the rfc2460 checksum and as the 
>> simple XOR'ing of the EUID's.  Why CRC32c?
> 
> RFC 2460 does not define the checksum, but the pseudo header. If 
> there's still legacy ICMP, TCP and UDP above, then it will be a 16bit
>  checksum, which is not exactly 'as good' as 32 bits CRC.

Yes, it's the ICMPv6 checksum rfc2463, four lines of text, sufficient to
implement.

When was the last time you saw a packet dropped because of wrong 
checksum; when was the last time you thought to yourself "hmmm,
maybe a better checksum is needed".

In what is CRC better than the ICMPv6 checksum, other than just saying
that one is 32 bit and the other 16.  How many messages have you seen
that were corrupted and not recognized as such by the ICMPv6 checksum
but were recognized as corrupted by CRC32c.  How many messages have you
seen that were correct and identified as corrupted by ICMPv6 checksum
but identified as correct by CRC32c?

> function.

Why using an IEEE-802 CRC when an IETF Checksum is available?

> For our purpose, it is needed only on RA-TIO which is not like on 
> every packet. And we can afford the 32bits in the TIO. So, why not 
> CRC32C?

Because cheaper and easier to implement and execute functions are available.

>> You seem to have a relatively clear picture of a certain RO 
>> mechanism, by assumption.  Is this RRH by any chance?
>> 
> 
> RRH was there before NEMO was a working group. Since then, RRH has 
> given us some good practise of Route Optimization. And yes, we found
>  that this was a very relevant information. Other drafts were 
> published for which the path was known by the HA, like 
> draft-na-nemo-nested-path-info-00. TD does not imply RRH. TD provides
>  a set of valuable information that RO can build on. The TD draft is
>  still 00. We can discuss about adding new fields, for instance as 
> optional suboptions - I hope we do it, actually.

What I'd like to discuss is about the problems that TD solves.  Are you
reluctant about discussing the actual problem?  Do you acknowledge that
the "looping problem" as raised in Issue 24 is not in fact a problem
that needs solution?

Alex