- To: "Benjamin Brown (E-mail)" <benjbrown@xxxxxxxxxxx>
- Subject: FW: [802.1] Per-priority Pause
- From: "Matt Squire" <MSquire@xxxxxxxxxxxxxxxxxxxx>
- Date: Mon, 19 Jul 2004 22:15:12 -0400
- Thread-Index: AcRqsYFE9b17w2OQRDGzu7vUu5nasADTdi5A
- Thread-Topic: [802.1] Per-priority Pause
fyi
> -----Original Message-----
> From: Norman Finn [mailto:nfinn@cisco.com]
> Sent: Thursday, July 15, 2004 5:16 PM
> To: STDS-802-1-L@listserv.ieee.org
> Subject: [802.1] Per-priority Pause
>
>
> Muneyoshi,
>
> On further consideration of your per-priority Pause proposal,
> I can see
> better the very good reasons why you proposed it, and would like to
> explain the rather violent negative reaction that your
> proposal received
> from some 802.1 and 802.3 people.
>
> When intelligent, competent people disagree strongly, the reason is
> almost always due to differing assumptions. I think I've found the
> different assumptions that we were making.
>
> For the particular diagram you were showing -- a telephone and a PC
> connected via a 100Mb repeater to a small media converter --
> a per-port
> Pause might be a cost-effective solution to a real problem. This is,
> of course, why you brought the idea into 802.1.
>
> The concern that I and others expressed was based on a different set
> of assumptions, namely, that 802.3 is a network medium, not an access
> medium. In a network medium, per-anything Pause raises all of the
> unsolved problems that were mentioned in the meeting. Per-anything
> Pause is simply a very bad idea for an IEEE 802.1/802.1 network, and
> probably, for any 802 network at all.
>
> This can best be explained by very slightly altering your diagram.
> Just add a printer to the repeater. Now, the per-priority Pause
> frames will stop the PC-printer traffic, as well as the PC-network
> traffic.
>
> Any solution to this problem that involves the PC recognizing that
> traffic to its printer is a different flow than traffic to the
> network can be trivially solved by telling the PC to limit its flow
> of traffic to the network to the contracted 20 Mbits.
>
> Placing the buffers in the proper device, according to the present
> 802.1 and 802.3 standards solve the problem very well. Perhaps that
> is your best bet for solving this access problem.
>
> -- Norm
>
> IEEE 802.1 list: see
http://www.ieee802.org/1/email-pages/tbyoc604.html