Subject: Re: Hashing function for PSAMP

From: Derek Chiou <[email-masked]>
Date: Tue, 01 Feb 2005 00:02:32 -0600

Happy is a difficult thing to say.

I agree with Stewart.  In general, if a router doesn't support it today, 
it won't.  Hardware cannot be changed and NP resources in extant boxes 
are already stretched to the limit.

That said, CRC32 is not a big deal in new hardware; my expectation is 
that the same is true for BOB (I'm not familiar with it.)  Thus, if it's 
a real requirement that router manufacturers see it as a serious 
differentiator that sells boxes, you will see it in future products.

Stewart Bryant wrote:

>
>> Are router development folks happy with the computational requirement
>> for BOB (or CRC32) to be computed on every packet, if it is used as the
>> selection hash? 
>
>
> The short answer is NO ):
>
> A lot depends on where you imagine this will be deployed.
> On a pure s/w edge router there will be a measurable
> headline performance hit with either of these, but perhaps
> that does not matter in that environment. On a hardware
> /microcoded core router, I would say that the chances
> of getting either in the main path of existing hardware
> are for all practical purposes zero.
>
> If you were thinking that they would be run after
> some primary sampler at a relatively low packet rate
> in the export process, then there is less of an issue.
>
> You canot use the existing CRC32 hardware to perform the
> hash. So both BOB and CRC32 would need new hardware or
> would need to be performed in software/microcode.
>
> Software CRC32 implementations trade lookup table space
> for compute cycles. Both of these resources are in
> critically short supply on a high-end forwarder.
> Even if you did find the resources (and on many
> implementations they would simply not be available)
> the result would be a crippling hit on headline
> forwarding performance.
>
> I have not done a detailed comparison of BOB and CRC32
> execution speeds, but my first impression is that BOB
> takes even more cycles to execute than CRC32 although
> perhaps not if you take into account the cache stalls
> in doing the table fetch.
>
> - Stewart
>
>
>
>
>
> -- 
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/psamp/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/psamp/>

---

From: "Saverio Niccolini" <[email-masked]>
Date: Thu, 17 Feb 2005 10:02:49 +0100

Dear all,
now that the meaning of "selection" is clarified I think
there is still the need of recommending one of the hash functions,
therefore I think the discussion we had still applies (just keep in mind
that instead of "mandatory" we have a "recommended"):
just make BOB recommended for packet selection and packet digest.

Best regards,
Saverio

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Tanja Zseby
> Sent: Wednesday, February 16, 2005 10:41 AM
> To: Benoit Claise
> Cc: Juergen Quittek; [email-masked]
> Subject: Re: Hashing function for PSAMP
> 
> Hi Benoit,
> 
> I fully agree. The discussion can be only about what we 
> recommend IF someone decides to implement a hash-based packet 
> selection.
> 
> Regards
> Tanja
> 
> Benoit Claise wrote:
> 
> > Hi Tanja,
> >
> > Thanks for the clarification/confirmation.
> > So I'm confused by the discussion in this thread, as it 
> seems that we 
> > are discussing a mandatory hash function? Doesn't it contradict the 
> > statement "you MUST implement at least one of the selection method 
> > described in the draft in order to be PSAMP compliant."?
> >
> > Regards, Benoit.
> >
> >> Hi Benoit,
> >>
> >> I remember that we decided that you MUST implement at least one of 
> >> the selection method described in the draft in order to be PSAMP 
> >> compliant.
> >> So I agree, it is sufficient to implement either a sampling or a 
> >> filtering method. We explicitely decided not to favor one 
> scheme over 
> >> another. The hash-section just gives recommendations for the case 
> >> that someone decided to implement a hash-based scheme.  I see no 
> >> reason to change this decision.
> >>
> >> Regards
> >> Tanja
> >> P.S.: if you have time, can you call me and give me the 
> list of typos 
> >> that you have on your paper version ? Or we make a short editing 
> >> session at the IETF ?
> >>
> >> Benoit Claise wrote:
> >>
> >>> Dear all,
> >>>
> >>> Regarding PSAMP compliance, I was under the impression that the 
> >>> agreement was (even If I could not find a trace of it, 
> after looking 
> >>> approx. 30 sec ;)):
> >>> If you want to be PSAMP compliant, you MUST implement at 
> least one 
> >>> of the "method" described in the draft.
> >>> So I concluded that one filtering or one sampling 
> mechanism would be 
> >>> sufficient.
> >>>
> >>> Now, the discussion below is about a compulsory hash function.
> >>>
> >>> Can we please clarify the situation regarding PSAMP 
> compliance, so 
> >>> where is/are the MUST(s):
> >>> - MUST implement one of the filtering or sampling 
> mechanism (note: 
> >>> hashing is a filtering function)?
> >>> - Or MUST implement one of the filtering and one of the sampling 
> >>> mechanism (note: hashing is a filtering function)?
> >>> - Or MUST implement one of the filtering, sampling, or hashing 
> >>> mechanism?
> >>> - Or MUST implement one of the filtering, sampling, and hashing 
> >>> mechanism?
> >>> - Or something else?
> >>>
> >>> From there, we will deduce if we even need a compulsory hash 
> >>> function...
> >>>
> >>> Regards, Benoit.
> >>>
> >>>> Dear all,
> >>>>
> >>>> Currently, the packet selection document has IPSX mandatory for 
> >>>> packet selection and CRC32 mandatory for packet digest.
> >>>>
> >>>> The problem I see with this recommendation is that IPSX is not 
> >>>> suitable for IPv6.  It does not sound like a good idea 
> to have it 
> >>>> mandatory for
> >>>> IPv6 systems.
> >>>>
> >>>> Here are two alternatives:
> >>>>
> >>>> 1. Make IPSX mandatory for IPv4 packet selection and BOB 
> mandatory
> >>>>   for IPv6 packet selection.
> >>>>   Then, with BOB implemented anyway, we should then replace CRC32
> >>>>   with BOB for packet digest, because both perform similarly and
> >>>>   there is no good reason for forcing implementors to 
> support also
> >>>>   a third hash function.
> >>>>
> >>>> 2. Just make BOB mandatory for packet selection and 
> packet digest.
> >>>>   This would simplify implementation, because only a 
> single function
> >>>>   is required.  For packet digest this should be OK, see 1.
> >>>>   A disadvantage is that BOB is slower than IPSX by factor 7.
> >>>>   An advantage is, that BOB is free of IPR, while IPSX 
> is protected
> >>>>   by a patent.
> >>>>
> >>>> Does anybody have a preferences for 1., 2., or the 
> current choice?
> >>>>
> >>>> Thanks,
> >>>>
> >>>>    Juergen
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> to unsubscribe send a message to 
> [email-masked] with the 
> >>> word 'unsubscribe' in a single line as the message text body.
> > to unsubscribe send a message to [email-masked] 
> with the 
> > word 'unsubscribe' in a single line as the message text body.
> Dipl.-Ing. Tanja Zseby			    	      	
> Fraunhofer Institute FOKUS			Email: 
> [email-masked]	
> Kaiserin-Augusta-Allee 31			Phone: +49-30-3463-7153
> D-10589 Berlin, Germany				Fax:   
> +49-30-3463-8153
> --------------------------------------------------------------
> ------------------------
> "Living on earth is expensive but it includes a free trip 
> around the sun." (Anonymous)
> --------------------------------------------------------------
> ------------------------
> 
> 
> --