Talk:Routing table/Archive 1

Endless Looping Problem
Isn't the endless-looping problem avoided by the 'time to live' in the packet header?

Hi,

The endless looping issue is not solved by the Time-To-Live (TTL) being set - this is simply a measure to prevent a build-up of endlessly-looping packets (a broadcast storm) - the recurring loop may still exist, but TTL prevents the packets accumulating in that loop.

Endless looping is circumvented using technologies such as route poisoning or split horizon with poison reverse.

Amigaholic 08:41, 28 December 2006 (UTC)

Lacking in context?
Hi,

I added a new sentence to the start of the 1st paragraph to try and give context to the introduction of the article. Is this sufficient, or is more needed?

Kind regards Amigaholic 08:42, 28 December 2006 (UTC)

Information that is placed in articles
From my converstation with an admin... Looking at your specific articles, I think they could be kept. Forwarding Plane does read like a manual in some parts. Phrases like "the next step" give it an almost how-to feel and should be rewritten or completely removed. The article is actually quite large for such a specific item, and tends to go off into the history of routers/processing. If you cut it down to just the specifics of the forwarding plane, it will probably have a more encyclopedic tone. If it's still not reading very well, maybe redirect it to Router (or whatever appropriate article) and include a section.


 * Control Plane seems to have the same problem; much of the article focuses on the use/installation/background noise, rather than the actual subject. It's also overly technical. I don't have a clue what "Routers, obviously, have local physical interfaces, and possibly logical subinterfaces, that have addresses in particular IP subnets." means...it's not so obvious. I think you're right that they aren't on a whole encyclopedic, and read like a text-book, but there might be enough information to make a proper article

So please remember that Wiki is not a manual or how to guide. It is not to go into great detail, that is what the cites do.

--User: (talk • contribs • count) 01:40, 4 July 2007 (UTC)


 * May I ask you (and the other contributors to this discussion) to take a look at something that may be analogous to the question of the level of detail in Forwarding Plane? As you point out, the forwarding plane article does show history and alternatives, as high-performance routers became more and more highly parallel, as in Parallel Computing.  There is a fair analogy, I believe, between the various classification schemes given for parallel computing. The various memory and bus models there have direct relevance to the way that routers have evolved to distributed/parallel processors.


 * In your opinion, is the Parallel Computing article also too detailed? This is not meant as a challenge, but an attempt to understand the Wikipedia style, and perhaps have both sections benefit. The Talk section for parallel computing also suggests that people are, to varying extents, unhappy.  The subjects of parallel computing and distributed forwarding are sufficiently similar that, I suspect, getting them at the same level of history and detail will solve many of the concerns.


 * The Parellel Computing article is written wrong. It may be deleted at any time. It is already flagged for not having cites. It does not have the proper intro. It is a mess.  Things I hope to avoid in our group. It cannot be classified as overtly complex it is to short, but it is too complex for a laymen.  A different problem.  So please do not use this article as an example.


 * Actually, it's useful to have an example of what you consider bad. Do you have some examples, in computing or other areas, where you think the level is right? I'm really not sure how I could make parallel computing much simpler other than to say "if the problem lends itself to being split into many smaller pieces, you can improve the performance by splitting the workload over many computational elements."  Having recently written some textbook material on parallelism, to go much beyond that, I'm not sure you can avoid being fairly technical. It is not trivial to think of multiple instruction streams, or avoiding interference by multiple processors accessing the same memory.


 * There are a substantial number of cites in Forwarding Plane, so that isn't the problem. Do you see it adequate simply to say that speedup, given physical limits of the speed of individual hardware components, requires spreading the load over multiple components and leaving it at that? Do you think, for example, that it's useful (I do) to mention that simply adding forwarders gets you a certain distance, but then bottlenecks at an improved performance level due to contention for the shared bus or memory? Howard C. Berkowitz 02:24, 4 July 2007 (UTC)


 * There is a fundamental issue, that runs throughout Wikipedia, of when something is "too technical". For example, I've found useful articles on pharmacology, but, when I refer a friend who doesn't have much exposure to organic chemistry or molecular pharmacology, the articles might as well have been written in Old Sumerian. With some articles in mathematics, I follow them thoroughly, but I only see the broad outlines in others, and yet others are incomprehensible -- and I know a good deal more math than the average person.   The fundamental issue is that some topics are inherently technical, and, to go into the details at all, there may be no way to avoid being technical.


 * I'm not being facetious when I ask if I stated the problem that Internet speeds are growing ever faster, and routers have to go faster and faster, is it appropriate to say that big fast routers need to be highly parallel, but not how the parallelism works? Is there a level at which I can say, about speeding routers so they can have 40 Gbps interfaces, "Need go fast. Gods say go fast need many processors working in harmony. Much magic. Tell secrets to wrong person and him turn into toad." Howard C. Berkowitz 02:00, 4 July 2007 (UTC)


 * You can get very technical but the infomation must be presented in such a way that it is not a reference for people who already know the topic. It need an intro for a laymen so anyone can grasp the concept first. Then it can get technical but from the intro, anyone must be able to understand what you are talking about.


 * also remember that what was true that is not true now must be preserved. So, when we talk about the Internet core and the Core router article that explains what a core router is on the Internet, just because the core no longer exists does not mean that the article gets revised. What happens is what I did.  There is a pointer to the subject concerning the core and then another pointer to your reference in Router to what a core router is.  Wiki has to keep and preserve what was along with what is.


 * A great example of this that I love is, the article on the battery size b. Whens the last time you saw a b battery?  But the article remains.  I need to go update that.  In any event I hope you see my point. --User: (talk • contribs • count) 02:31, 4 July 2007 (UTC)

Removed Merge Tag added Function section
Routing tables are stored and used as well as created in end copmputers. This would mean there is a much broader scope that just in a phys. router. Although one could argue that the network card in a pc is a router, the laymen will not see this. Therefore this article can stand on its own. Furthermore I have expanded this article with the Function part and added a few term so we could place redirects to the proper section. --User: (talk • contribs • count) 17:33, 4 July 2007 (UTC)