I'm glad we're discussing this. I mentioned that CCIE used to have questions like this, but it occurred to me that CCNA expects you to understand flow control too! This is an important conversation.
In your printing example, Scott, you've got flow control running at lots of different layers! Indeed that can be "chatty." NetBIOS can do flow control. TCP can, of course. I don't know if RPC does or if SPOOLSS does. SMB doesn't have any flow control built into the protocol, but since it deals with transferring files, there's going to be some natural flow control as it reaches out to the hard drive to get blocks of data from the files. Back to TCP. What triggers TCP flow control? One thing could be dropped packets at the switch in the example. TCP does do slow start nowadays, though, to help it avoid sending so fast that internetworking devices in the middle drop packets. TCP should adjust to the mismatch situation of the server being on 100 Mbps and the client being on 10 Mbps. Someone else mentioned IP Source Quench. That can no longer be used by routers (per RFC), though end hosts could use it, but they generally don't (except old versions of Mac OS. You gotta love Apple! :-) However, TCP isn't the only protocol out there! There are lots of protocols (and entire protocol stacks) that don't do flow control. That doesn't mean that Ethernet needs to do it with Pause frames, but something has to give. When there's a speed mismatch, a switch or router simply has to drop packets at some point. It can't have infinite buffers, and you wouldn't want it to have infinite buffers because then stuff could lie around in the buffers for too long. If you don't like my switch example, how about a router that connects 100Mbps Ethernet and 1.5 Mbps T1 with heavy traffic flowing across? At what point will it start dropping packets? Saying that this won't happen in the real world is not an acceptable answer. :-) It could happen and router and switch vendors architect for the situation. I don't know how many buffers a router or switch might have, though. That's a good question. It wouldn't have all buffers of the same size, like in my example, but I didn't want it to be too diffcult! But having 1000 buffers as in my example might be realistic? I could say 10,000 buffers, but there's still a problem at some point. If there were really that many packets queued up in a buffer, upper layer protcols might start freaking out if the queue doesn't get emptied quickly. More later on possible ways of looking at the original problem. Priscilla s vermill wrote: > > And as a follow up to the below, I just captured a print job on > our corp network using Ethereal. I run Win2k Pro. Don't know > anything about the print server itself. Here's what I saw... > > Microsoft Spool Subsystem (SPOOLSS) / DCE RPC / SMB / netBIOS / > TCP > > VERY chatty. I don't see how 10M could ever be achieved in the > first place. Lots of queries and replies (i.e. lots of > processor interrupts and the like). > > Then I did a large file transfer from one of our file servers > to my desktop. Here's what I saw... > > NetBIOS Session Service (NBSS) / TCP > > carrying the actual data and > > SMB / NBSS / TCP > > doing the control function. > > Again, VERY chatty (I realize this may be pretty elementary > stuff for a lot of folks on the list but some of us don't get > too far up the protocol stack when it comes to this sort of > "user client-server" interaction, so please bear with me (I do > deal with VERY large TCP and UDP exchanges between servers from > time to time but there are never any speed mismatches to be > dealt with)). In both of the above cases, TCP would have > prevented too much packet loss from taking place even if there > had been a choke point, which apparently there wasn't. Even > with something like TFTP, which relies on UDP, each and every > block is acknowledged at the application layer (I think), so > there likely wouldn't have been any loss there either. > > I'm just not sure there's a good real-world example to help us > with the theoretical "what if" question. In what scenario > would a large transfer of data be attempted with out any type > of flow control in the stack somewhere? > > Scott > > > s vermill wrote: > > > > Steven, > > > > Thanks for sharing. A real example is just what the doctor > > ordered. In your below example, did the print transaction > rely > > on TCP at L4? I've captured some print traffic on our corp. > > network in the past and I'm pretty sure it was TCP. Don't > know > > if there was a speed mismatch between the server and the > > printer though. > > > > Scott > > > > Steven Aiello wrote: > > > > > > Ok, I am still a lowly CCNA however Einstein said make > things > > > as simple > > > as they need to be and no more. I work on a LAN where we > > > transmit large > > > print files to Xerox laser printers. These files can get up > > to > > > 1.5Gb in > > > size and sometimes a bit larger. The Printers run on older > > Sun > > > workstations and they have 10Mb cards. I have never come > > > across a > > > situation where the server has been able to over flow first > of > > > all the > > > switches buffer and second of all it's NICs buffer. I know > I > > > am not the > > > only sys admin who randomly sits on the network with a > packet > > > sniffer > > > and analyses traffic from the major sources of traffic on > > their > > > network, > > > yes sometimes there will be some retransmit requests by the > > > Xerox > > > workstations however nothing of large significance. Also > > these > > > retransmits usually occur when another workstation is > > > processing a > > > separate file also about 1Gb or more and that data is being > > > transferred > > > over the network from workstation so the server. Also what > > > kind of > > > network environment would you be in where your server would > be > > > slammin > > > one workstation? Even real-time video would create this > type > > > of > > > overload, especially since I can imaging it would be run > over > > > UDP and > > > packets would be dropped if they were out of order. > > > Theoretically you > > > may be able to overwhelm a 10base T card however I would > even > > > doubt that > > > considering the windowing and source quenching built into > > > TCP/IP (source > > > quench may be the wrong term but you all should know what I > am > > > talking > > > about). I think it is far better to have the bandwidth > ready > > > and > > > available then to fall short. > > > > > > That's just my opinion on the humble, > > > Steven > > > > > > > > > > > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=65375&t=65263 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
