Training the next generation:

Tue Aug 24 15:02:04 UTC 1999

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 ----- 
From: Dan Cohn <dan at internap.com>
To: Dana Hudes <dhudes at panix.com>
Sent: Tuesday, August 24, 1999 2:02 AM
Subject: Re: Training the next generation: 

> 
> 

> 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.
> 
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 
> > uses Tannenbaum's _Computer Networks_ and tries to cover a range of things.
> 
> 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. 

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 
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.

>  
> >Course project will likely be design and implement a bridge, possibly
> >including source-route and certainly including spanning tree. 
> 
> 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. 
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.

> 
> 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.

> 
> > 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.
> 
> 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.

>   
> > Spring is a "special topics" course. I've some flexibility here. I'm weighing 
> > 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 
> > syllabus from Purdue as a starting point. No time in this course for any 
> > 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.
> 
> 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. 

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.

> 
> > Comer's graduate course has students build a router but this is probably
> > too much for undergraduates. 
> 
> 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.

> 
> >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 
> > to make the 2 semester sequence in networking we'd hoped; maybe next
> > year).
> 
> 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. 

> 
> > 
> > 2. Network application programming. Java clients, Perl and Apache 
> > 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.
> > 
> 
> 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.
>  

The gaming system is bigger than you think. Consider GUI client. There is the question of 
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. 
> >Given this, which of these options is better for the industry? 
> 
> Presently, people who understand network engineering from a routing,
> design, and troubleshooting point of view are in extremely high demand. 
> 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.  

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. 
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.

> 
> 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

> 
> Thanks,
> 
> Daniel Cohn
> Senior Network Development Engineer
> InterNAP Network Services
> Seattle, WA
> 
> 