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=65364&t=65263
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

Reply via email to