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

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Tue, 31 Aug 2004 11:32:55 +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?

We are in a loop. I already passed you the RFC that details all this.
But yes, roughly specking, 32 bits is better than 16.

> > We now have a standard, readily available, for a robust 32 bits
> > 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.

Functions are available for both, as I already pointed out, even in open
source environment. This is a minor issue and I'll take the vote from
the WG when we make one. Please come up with the question.

> 
> >>> 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.
> 
> 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?
> 
I started a thread for that. The current one has done its job, we
started looping and I'll not sure anyone is reading it anymore. Like
NEMO with issue 24 :) I do believe we need to do something for that
issue, while I also agree that the answer in the issue is valid and
sufficient for some configurations - thus moving forward with the draft
as is.

Pascal

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 31 Aug 2004 12:12:09 +0200

Pascal Thubert (pthubert) wrote:
>>  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?
>> 
> sufficient for some configurations

I partially agree with you; yes we were a bit verbose, sorry to audience :-)

I agree TD is a protocol.

I don't agree to send CRC's without the associated data.

I agree the answer in issue 24 "looping" is valid and sufficient for
some if not all configurations.

I don't believe currently TD solves any stated problem, has no
associated NEMO Charter item.

> - thus moving forward with the draft as is.

You mean the NEMO basic support draft, right?

Alex