[24947] in North American Network Operators' Group
Re: Training the next generation:
daemon@ATHENA.MIT.EDU (Dana Hudes)
Tue Aug 24 11:03:39 1999
Reply-To: "Dana Hudes" <dhudes@panix.com>
From: "Dana Hudes" <dhudes@cncdsl.com>
To: "Dan Cohn" <dan@internap.com>
Cc: <nanog@merit.edu>
Date: Tue, 24 Aug 1999 11:02:04 -0400
Errors-To: owner-nanog-outgoing@merit.edu
Dan,
thanks for the input. IP routing research is a subject near and dear to =
my heart.
I have wanted, for a long time, to do some work on traffic engineering =
using flow optimization algorithms
from the literature applied to BGP policy. Do you think this is =
sufficiently interesting and useful to InterNAP that they could come up =
with funding ? In our business not too many PhDs with operational =
experience so a fellow with the operational experience and a Master's =
(me) might suffice.
As for the coursework:
----- Original Message -----=20
From: Dan Cohn <dan@internap.com>
To: Dana Hudes <dhudes@panix.com>
Sent: Tuesday, August 24, 1999 2:02 AM
Subject: Re: Training the next generation:=20
>=20
>=20
> I think you are right on approaching the computer networking industry. =
We
> are always short talented engineers, and spend a great deal of time
> seeking the few that are available.
>=20
I was a 1st line manager with hiring responsibility for 2 years; while =
working for Bay Networks Consulting I interviewed candidates there as =
well. Very hard to find anyone with a clue and analytical skills.
So I'm out to make some.
> > Fall course is "Telecomputing"; the syllabus I created for the =
course=20
> > uses Tannenbaum's _Computer Networks_ and tries to cover a range of =
things.
>=20
> It may be a bit late to suggest this, but please keep in mind for the
> future an alternative text, entitled "An Engineering Approach to =
Computer
> Networking", by Keshav.=20
Interesting. I shall have to quickly check it out.
>While Tannenbaum has long been recognized as a
> solid foundations book, Keshav's material is much less esoteric, more =
up
> to date, and replaces complex statistical mathematics of little use to =
the
> common network engineer=20
You think Tannenbaum is bad, look at Grodzinsky. I about fell off my =
chair when their network simulation exercise involves MathCAD! The =
introductory exercise involves a bit of FFT using Maple. I know neither =
of these programs, but I've seen that they are now used in undergraduate =
mathematics education extensively (when I took calculus and D.E. etc. it =
was the same as always had been -- lecture + recitation + homework with =
pencil and paper). Nonetheless Grodzinsky has some good projects for =
students to implement various network aspects so I chose it as 2nd text =
for the class.
>with practical examples from real-world production
> networks. I believe you will find the Keshav course material is as
> comprehensive as the Tannenbaum book, but much more fun to read.
Sounds great. Wish I'd had this information four weeks ago when I chose =
the book for the course. Class starts Monday.
> =20
> >Course project will likely be design and implement a bridge, possibly
> >including source-route and certainly including spanning tree.=20
>=20
> Unfortunately, the term 'bridge' has not been used actively in =
computer
> networking for a number of years, and when it has it generally refers =
to
> either a concept or support for a legacy environment. Spanning tree is =
a
> very important protocol, and can form the conceptual base for many
> protocols which followed it, but may not deserve more than a few days
> coverage, especially in an introductory class designed to prepare =
students
> for current and future technologies. 'design and implement a bridge' =
is
> slightly troubling to me, as bridges are fairly passive devices which =
are
> generally avoided in current practice.. Unless you intend to have the
> students actually write an implementation of spanning tree, this task
> should involve little more than plugging two devices into a hub.
When I say build a bridge, I mean write one in software.=20
Complete with spanning tree implementation, BPDUs etc.
A LAN switch acts like a multiport bridge. It just has hardware assist =
to move frames around.
BTW, I build bridging in to use the facility in a WAN switch rather than =
let it do IP forwarding.
Remote city dialup (multiple chassis, each 2xDS-3 dial trunks) comes to =
ATM switch Ethernet interface and is bridged to remote router which has =
an ATM PVC configured for ATM Half Bridge. No spanning tree. Only the =
remote ATM switch knows its bridging, the central switch just pushes the =
ATM cells to the router.
>=20
> Source route bridging, on the other hand, while slightly more complex, =
is
> also considered a legacy protocol, and efforts are being made wherever
> possible to replace SRB networks with scalable, routable alternatives.
SNA will never die completely. Wish it would. Keeps coming up.
> Again, in my own teachings, this is a topic which usually gets a few =
hours
> in passing, as a legacy protocol which hopefully no student will
> encounter.. and when they do encounter it, it will most certainly be =
for
> the purpose of finding a migration strategy to something more =
scalable, be
> it SNA over DLSW, or a full migration to IP.
I agree that SRB first of all is an extra complexity students don't need =
and is of lesser importance.
I will introduce the real nasty, translational bridging real quick and =
explain why we don't do such things.
>=20
> > Early on, coverage of WAN include project with PCM and such.
> > A syllabus is posted at http://harmony.hudes.org/Telecomputing.html
> > Students will have a broad base in a variety of networking topics.
> > Focus on Ethernet in the LAN and PPP and ATM in the WAN.
>=20
> Excellent material. Be mindful of the order at which you bring in
> discussion of ATM, as it does not strictly conform to the OSI model, =
which
> should be well understood before ATM is discussed, IMO. A good segue =
into
> ATM is Frame Relay, which is still rather prolific in the industry.
Tannenbaum doesn't try to cover ATM all at once. He splits up the =
coverage according to the OSI layers.
Notably, in this 3rd edition layers 5 and 6 are just about gone. That's =
fine for router engineers but ironically things like XBR are =
presentation layer and important to client/server programmers. I suppose =
one can shove XBR into application layer.
> =20
> > Spring is a "special topics" course. I've some flexibility here. I'm =
weighing=20
> > two alternatives, and want some feedback. Of all possible things, =
the
> > acting chair and I narrowed to two possible courses:
> > 1. A course in TCP/IP. Use Comer, _Internetworking with TCP/IP_ and =
his=20
> > syllabus from Purdue as a starting point. No time in this course for =
any=20
> > physical layer or data link stuff beyond a cursory overview of =
Ethernet
> > as we move at high speed to the network layer and IP forwarding.
>=20
> This is a good text, and you are likely correct about the timeframe. I
> encourage you to also delve into some projects from Network =
Programming by
> Stevens, if your students are expected to have a certain degree of
> competency with programming for Unix in C, as this tends to really =
cement
> the learning process. Good projects include having students write an
> implementation of nslookup, talk, or ftp from scratch, using the RFCs =
as a
> resource.=20
Interesting project idea instead of having them work on routing =
protocols.
But, source to all the things you mention is readily available. OSPF =
source isn't quite so easy to find.
>=20
> > Comer's graduate course has students build a router but this is =
probably
> > too much for undergraduates.=20
>=20
> Quite true.. routers are complex things. This is a project for people =
who
> not only are already extremely comfortable with the network layer
> protocols they are implementing towards, but also who have a good =
grasp on
> multiprocessing, have a fairly good understanding of routing =
protocols,
> and have significant experience writing network code.
Even a simple router is pretty complicated. But if I use UNIX (or NT) as =
a base, we skip ahead
to routing protocols and don't have to implement IP forwarding.
Multiprocessing they get from the OS course.
>=20
> >Instead an OSPF implementation, including all the options (especially
> > NSSA) . A cursory introduction to sockets programming with the =
course
> > focus on routing algorithms (i.e. RIP, OSPF, and BGP4).
> > Can this one course (my fall course hasn't sufficient registration=20
> > to make the 2 semester sequence in networking we'd hoped; maybe next
> > year).
>=20
> Please, please include ISIS and some discussion of emerging multicast
> standards in this discussion. Students familiar with emerging dominant
> technologies are much more marketable and useful than those who know =
what
> everyone else has already learned from experience. Much too little
> emphasis is placed on ISIS and multicast considering the likelihood =
for
> their relative abundance in the future.
Interesting that you put ISIS as an emerging rather than past protocol.
Multicast is on my agenda somewhere. They're in good shape to deal with =
such things given the heavy data structures background they bring to =
the course (discrete structures is 1 semester, then 3 semesters of =
algorithms + data structures; all in C++). Certainly I shall include it =
somewhere in the Telecomputing course; the spring also should have =
something about it but not sure yet where and how.=20
>=20
> >=20
> > 2. Network application programming. Java clients, Perl and Apache=20
> > server side (or perhaps Java servlets). Hunter students know C++ =
fairly
> > well by their senior year; Java is an easy transition. The entire =
class
> > would divide into teams with assignments that comprise various parts =
of
> > the client and server portions. The project would be a turn-based
> > simulation game (I used to play these and have a number of =
appropriate
> > games with play-by-mail options, game rule design and/or game theory =
is
> > not part of the course). While this won't teach them to be router
> > engineers -- or developers, it should have some industry relevance.
> >=20
>=20
> By the time a student reaches their senior year, they should be very =
well
> capable of writing the entire gaming system on their own, including =
client
> and server components. Systems like this generally do not involve very
> much network code, and dividing it up too much would be a shame. =
Please
> also consider having your students do some of this work with CORBA, =
and
> implement different components in a few different languages. Again, =
make
> your students useful because they have done what other people are =
starting
> to do or thinking about doing, not because they have done a little bit =
of
> what everyone in the industry already knows very well how to do.
> =20
The gaming system is bigger than you think. Consider GUI client. There =
is the question of=20
the application protocol for communicating moves etc. .
The trouble is that there is a considerable amount of non-network =
related design and implementation (e.g. the economic system, combat =
system etc.). It really is a fine line between such a project and =
distributed systems.
After all, the user should not see the network in such a game.
> > Most Hunter graduates stay in the Greater NYC metropolitan area.=20
> >Given this, which of these options is better for the industry?=20
>=20
> Presently, people who understand network engineering from a routing,
> design, and troubleshooting point of view are in extremely high =
demand.=20
> People who can write some network enabled code are in relatively small
> demand. Salaries for the former in NYC start at abt $70k, salaries for
> the latter start at $35-40k. Concentrate on IP routing, emerging
> technologies in IP routing, and coding to solidify that understanding, =
is
> my advice. =20
Thanks. But, this isn't an operations course. Rather, to prepare them to =
work for Lucent/Ascend, cisco, Bay, etc.
in building the stable products network architects require. Network =
architecture, properly done, involves traffic engineering.=20
Where exactly do you want the traffic to flow. Rather than optimize at =
the AS level, a computer can create a policy to optimize at the prefix =
level (you are, after all, already doing per-prefix filtering if you're =
careful). Regardless of the goals and constraints.
So many of the folks configuring routers *can't program*. Not a bit. =
They're former electrical engineers. In fact, I've had agencies tell me =
I'm not qualified for the position of network engineer because my =
degrees are computer science not electrical engineering. Who do they =
think builds routers, EEs alone? Eek.
Musicians write better code than most EEs I've seen.
>=20
> Feel free to call on me if I can be of any assistance in your planning =
or
> during the instruction of your course,
Well, any of you folks who happen to have any old (or new, you =
manufacturer folks here's a chance to get your new toys in front of the =
next generation) network equipment you can donate or loan to Hunter to =
build up our network student lab we would appreciate it. I don't take =
such directly, but please contact me if you can help and I will make the =
introductions all around to make it happen.
Thanks very much to all for the feedback.
It sounds like both my courses are needed but the IP course is better. =
That's somewhat expected from this crowd.
Dana Hudes
>=20
> Thanks,
>=20
> Daniel Cohn
> Senior Network Development Engineer
> InterNAP Network Services
> Seattle, WA
>=20
>=20
