In message <Pine.LNX.4.61.0506171256340.19644@m24s24.vlinux.de>,
Hubert Feyrer writes:

>
>Welcome to NetBSD, Ivo!
>
>On Fri, 17 Jun 2005, Ivo Vachkov wrote:
>> After all, IMHO, these projects are supposed to make CS students
>> familiar with NetBSD and optionally gain some ideas or implement some
>> feature. I doubt someone expects proffesional level in design and
>> algorithms or 100% bug free implementation.
>
>I think it would be a waste of everyones time to do the SoC project with a 
>sub-standard goal in mind, only to justify its existance but which gets 
>thrown away later. Instead, I'd rather see only a proper(!) design 
>document only, that others can work on from.

Exactly.  These days, if someone sees the words "policy-based routing"
and 'NetBSD" together. then they might reasonably expect a BSD-quality
implementation of policy-based routing.

By that, for discussion purposes, let's agree that means an efficient
implementation capable of handling 100,000 to 250,000 rules, each a
5-tuple or more; and also capable of packet rates of 500,000/sec, on
machines capable of somewhat over 500,000 packets/sec now.
(but does does that sound like a summer-intern project??)

Or, alternatively, an (src-ip, dst-ip) route/next-hop lookup,capable
of efficiently handling a dozen or so local addresses with negligible
slowdown in peak packet rate.

Or, an IPv6 flow-forwarding engine.

I'd guess that first option would make a perfectly reasonable Masters'
project for an M.Phil (Masters by dissertation): far beyond the scope
of a summer-intern project.  The second would be a very challenging
summer project; possibly too much. The third, I don't know, but I if
it hasn't already been done by leveraging IPv4 flow-forwarding, then I
suspect it's a challenging propostion.

What I think _is_ doable as a summer project boils down to: yet
another linear-search of an ordered list of tuples. OTOH, we already
have two (or is it three?)  of those. And I'm with Hubert: that's a
project which is very likely to be later thrown away entirely, if/when
the more ambitious projects are tackled.



>As such, Jonathan (leaving out the aggrssion) 

I didn't intend any aggression. Frustration, yes: largely at the
prospect of setting a student eitehr an unattainable goal, or a
project downscoped so far that it's achievable in one summer but of
little value.


>gave some interesting points 
>here, together with even some pointers for reading up on the matter, which 
>someone interested in the matter should probably follow, and then work 
>with NetBSD's people (or maybe just one, his SoC mentor) on the design
>and implementation.

Hopefully the SoC mentor (if chosen for SoC) has sufficient clue to
guide the student to a reasonable, achievable, yet worthwhile,
project.  I see good reason for skepticism on that front.

Suggesting yet more choices (yet more viable summer projects),
such as multipath support, only makes the matter worse.


>I think for NetBSD, the design document should be reviewed.
>I'm not sure this should happen in all its length for the SoC project, as 
>it would burn a lot of time while work on an initial prototype could be 
>done instead.

That, too.