Chuck ,
I agree that if you don't have an input buffer you
simply drop the packet . This is so with a router and
this is so with a switch . You can use any queueing
mechanisme you like but in the end if you have no
buffers you drop the packet .
In the thread someone came up with the existence of
'pause' frames . This is actually an annex to the
gigabit spec that defines a means of flow control by
using those pause frames . Like an send/no send
mechanisme . Certainly not all hardware in the Cisco
switches and available NIC's supports this mechanisme.
This is gigabit , the original pause was about 100Mb.
Is this 'pause' frame also implemented on 100Mb links
?
Besides if you think of it ;
PC/100MB ==== switch ==== 10Mb
Lets consider a point to point links between PC and
switch.
The switch can handle the 100Mb comming from the PC.
The switch is capable of switching the 100Mb stream to
the 10Mb port . So the output buffers on the 10Mb
switch port are suffering , in keeping up with the
traffic coming from the 100Mb port.
So were do you drop the packets ?? On the output queue
at the 10Mb port . This makes it more difficult to
implement the pause mechanisme on the 100Mb port .
Infact the 10Mb should signal the 100Mb port that it
cannot handle the packets otherwise the 100Mb port
will never know and never send a pause frame to begin
with .
Imaging now that there are other ports switching
frames to the same 10Mb port . What to do now ?
Pc1 100Mb====switch ====10Mb
Pc2 100Mb====
Lets say PC1 one is streaming like hell to the 10Mb
port . Lets say Pc2 behaves and is sending packets in
a moderate fashion to the 10Mb port .
How to implement the 'pause frame' mechanisme ?
Real live switch is immense more complicated than the
senarios above .
This 'pause' thing makes sense if you have a one to
one connection with similar speeds . I fail to see how
this mechanisme can solve the 100Mb---10Mb buffer
problem .
I do not think that is was indendent to solve this
type of problems in the first place .
Thats what I make of it ,
flem
--- Chuck Larrieu <[EMAIL PROTECTED]> wrote:
> Just wanted to put this discussion into a summary
> form. Hoping that I have
> learned something. Hoping to help others learn
> something.
>
> The original question can be generalized to this:
>
> Host_1------Device-------Host_2
>
> Host one is transmitting at 100 mbs and host two can
> only receive at 10 mbs
>
> The question is "what happens to the excess packets
> when Device is
> overloaded like this?"
>
> S wrote out the following table:
>
> If Device is: what happens is:
>
> Repeater just does what it's told. If the wire is
> full it is higher layers
> that deal with it
>
> Ethernet CSMA/CD determines what goes onto the wire
> in the first place.
> Collisions will occur. Or bits won't get onto the
> wire in the first place
> because the medium is saturated. Medium MTU effects
> Host_1 transmission rate
> as well.
>
>
> Token ring possession of the token determines a
> stations ability to transmit
> data. Medium MTU is a factor here as well.
>
> Frame relay if a frame switch is saturated, packets
> are dropped and FECN's
> and BECN's are generated
>
> ATM I believe that the admissions control process
> limits the acceptance of
> cells into the ATM switch. Correct me if I am wrong
> here.
>
>
> I find I am a bit shaky on 100VG, X.25 ( like I
> care, since it isn't on the
> Lab any more :-> ), and HDLC
>
> Lastly, the issue the original post raised - a
> switch.
>
> In the reading of the this thread, and the reading
> of some of the
> references, what I am determining is that if there
> is some kind of
> flow control mechanism, it comes probably in the
> form of the switch creating
> false collisions on the port of the sender, so as to
> stop it
> from overflowing the switch buffers.
>
> The point being that in terms of layer two, the
> general means of dealing
> with too much input and not enough output is still
> generally speaking,
> massive dropping of excess packets, or some
> limitation of the medium itself
> to limit acceptance of new packets onto the medium.
>
> Which is as it should be, I would think.
>
> Any comments? Does this make sense?
>
> Chuck
>
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]] On Behalf Of Flem
> Sent: Thursday, January 11, 2001 9:56 PM
> To: Chuck Larrieu
> Cc: [EMAIL PROTECTED]
> Subject: RE: switch flow control
>
> One of us needs a pair of glasses ;-) I read ;
>
> minimal specification for asymetric flow control
>
> Has to do with flow control.
>
> If you say a device to pause , process the buffers
> and
> then release the pause is indeed a minimal form of
> flow control .
>
> I never played with set port flowcontrol so I
> getting
> impressed ....
>
> I loved the old style no buffer , drop packet .
> Things are really getting more complex is it not ?
>
>
> flem
>
> --- Chuck Larrieu <[EMAIL PROTECTED]> wrote:
> > Guys, this "pause" frame does not appear to have
> > anything whatsoever to do
> > with flow control of data transmission. Unless I
> am
> > blind as a bat I am
> > reading the link below to be referencing auto
> > negotiation of links between
> > NIC and switch or any device on a port and
> switch..
> >
> > Look, if a switch cannot output data as fast as it
> > comes in, and the buffers
> > fill, then packets get dropped. Same as with a
> > router. or a PC.
> >
> > Chuck
> >
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]] On Behalf Of Flem
> > Sent: Thursday, January 11, 2001 9:17 PM
> > To: [EMAIL PROTECTED]
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: switch flow control
> >
> > Or ;
> >
>
http://grouper.ieee.org/groups/802/3/z/public/presentations/jan1997/HFpsbits
> > .pdf
> >
> > Written by a cisco guy ... you are rights cisco do
> > implement it.
> >
> > flem
> >
> >
> > --- Chris McCoy <[EMAIL PROTECTED]> wrote:
> > > This is true...sorry. I was reading a cisco
> > > document
> > > on the Cat 6000s where they explained flow
> control
> > > as
> > > being 802.3Z flow control. I screwed up...(see
> > >
> >
>
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/sft_6_1/configgd
> > /ether.htm#xtocid170110)
> > > Come to think of it...it's called 802.1x
> > > (http://www.ieee802.org/1/pages/802.1x.html).
> > Cisco
> > > supports it with some exceptions (set port
> > > flowcontrol).
> > >
> > > Guhhhh....
> > >
> > > Chris M.
> > >
> > > --- Flem <[EMAIL PROTECTED]> wrote:
> > > > 802.1Z ? or 802.3z ?
> > > > This is gigabit stuff is it not ?
> > > >
> > > > Is cisco implementing 802.3z on his gigabit
> > > > switches ? Don't think so .
> > > > Switch will buffer , if no buffer , then drop
> > > > packet.
> > > >
> > > > Do you know what vendor implements pause
> frames
> > ?
> > > >
> > > >
> > > > flem
> > > >
> > > >
> > > > --- Chris McCoy <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > 802.1Z or 'pause frames'
> > > > >
> > > > > Chris M.
> > > > >
> > > > > --- Flem <[EMAIL PROTECTED]> wrote:
> > > > > > Between NIC and switch ?
> > > > > > What is the name of this handshaking ?
> > > > > >
> > > > > >
> > > > > > flem
> > > > > >
> > > > > > --- Circusnuts <[EMAIL PROTECTED]>
> wrote:
> > > > > > > I believe there is a handshake going on
> > with
> > > > the
> > > > > > > switch & NIC
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > ----- Original Message -----
> > > > > > > From: "Rick H
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Photos - Share your holiday photos online!
> http://photos.yahoo.com/
>
> _________________________________
> FAQ, list archives, and subscription info:
> http://www.groupstudy.com/list/cisco.html
> Report misconduct and Nondisclosure violations to
> [EMAIL PROTECTED]
>
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
