At 2:39 PM -0400 4/20/02, Priscilla Oppenheimer wrote: >At 11:05 AM 4/20/02, Howard C. Berkowitz wrote: > >>A way to approach this may be more a test engine presenting "word >>problems" and asking something subtly different than what CCIE >>written practice materials do. Those practice tests ask for a >>solution to the problem. If the problem descriptions perhaps could >>be made a little more detailed, and the question is asked "what is >>significant about this problem that would make you choose a >>particular solution?" as distinct for asking about the problem >>itself, perhaps followed by a conventional question about the >>solution. I'll try to create some examples and post them. > >That sounds like a good idea. In this way you could test that the person >understands methods and processes, not just specific situations. > > >>Let's take a networking parallel. What if the server people are >>having application response time problems, and start blaming the >>network. You are called in by the IT manager, who, we shall assume, >>is quite network-literate. You do some tests, and turn to the manager >>and say "the TCP window size for this application do slow start and >>then grow normally." What _negative_ information have I just >>conveyed about this being a network or host problem (there are >>several possible answers, all related)? > >You have implied that the problem is not with the network. TCP starts in >slow start and then adjusts its window size based on congestion. You say >that the window grows "normally," which implies that congestion isn't a >major problem. The IT manager should start troubleshooting potential server >problems: slow disk, small cache, non-optimized database, that sort of thing. > >This is just a guess, but hopefully on the right track of one of the >possible answers. > >Priscilla
Definitely one possibility. Another reasonable thing to infer, before getting paranoid, is that the network has an insignificant error or loss rate, since TCP assumes loss of acknowledgement for whatever reason is due to congestion, and backs off. Getting a bit paranoid, however, there certainly are TCP implementations that either were just done wrong. Other implementations deliberately violate the implicit flow control rules in order to look better for throughput benchmarking. A good TCP benchmark not only measures throughput, but introduces errors to be sure the backoff mechanism works. Now, a question to the group. I encourage people to pose these sorts of scenarios here, and I'll create more as a separate thread, "method and process scenarios." So that vendors can provide things that are useful to people studying, would there be interest in either hard copy or online collections of such things? Priscilla, would this sort of thing lend itself to your flash cards, or is the answer apt to be too long? Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=42091&t=41955 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
