Subject: LinkDelayAllowance object?

From: Andrew Smith <[email-masked]>
Date: Wed, 3 Feb 1999 14:34:40 -0800

OK - enclosed is Geoff Thomson's explanation of the object. He does not have
an opinion on whether it ought to be manageable or not. I don't know anyone
who exposes this for user twiddling.

Modifying this value has the effect of either lengthening or shortening the
time for which a device would assert PAUSE flow-control to upstream
neighbours. This is applied to a basic "PAUSE delay" value handed down from
the application above the MAC (see below). 

I guess the real problem here is the following: IEEE 802.3x&y-1997 section
30.3.4.1 calls out aPAUSELinkDelayAllowance as a managable parameter, in
units of bits, of ("the allowance made by PAUSE MAC Control entity for
round-trip propagation delay of the full duplex link"). But section 31B.2
leaves it up to the entity sitting above the MA_CONTROL interface to choose
the basic delay, in quanta. I do not see much use in exposing the
LinkDelayAllowance as a manageable parameter - it is really the entity above
the MAC that needs a manageable parameter for the pause time that it is to
request of the MAC. So, it is things like the Bridge MIB, a "Host MIB" or a
"Router MIB" that are the ones that need (?) the manageable parameter. This
is what Lynn was refering to I think.

Reality check: I don't see any host or router vendors as being very
interested in managing such parameters through SNMP. I think there are 2
types of switch/bridge vendors (a) those that understand congestion-control
and decide to use adequate buffering and/or separated traffic classes to
manage congestion (b) those who think flow-control is the best thing since
sliced bread for solving world hunger. But that quickly gets to be a
religious war.

Anyone, feel free to speak up on the bridge MIB WG list if you feel that the
bridge MIB needs such a manageable object -
http://www.ietf.org/internet-drafts/draft-ietf-bridge-bridgemib-04.txt is
currently in WG last call.

Andrew

> -----Original Message-----
> From: Kubinec, Lynn [mailto:[email-masked]]
> Sent: Tuesday, February 02, 1999 8:47 AM
> To: 'Dan Romascanu'; [email-masked]'
> Cc: [email-masked]'; [email-masked]'
> Subject: RE: draft-ietf-hubmib-etherif-mib-v2-02.txt
> 
> 
> Hi Dan,
> 
> I've gone back through some of the mail I have on the subject
> and find that John is quite correct...no one has yet given
> an explanation of how setting this value is used in the MAC
> Control pause function.   You think it affects the Pause 
> Functionality, how?  Andrew Smith thinks it would be dangerous 
> to modify it...Andrew?  Why?  What would modifying this value do?  
> 
> I think the wrong thing is being "managed" here...I think
> pause quanta would be an interesting thing to manage...
> 
> Lynn
> 
> > -----Original Message-----
> > From: Dan Romascanu [mailto:[email-masked]]
> > Sent: Tuesday, February 02, 1999 9:58 AM
> > To: Kubinec, Lynn; 'John Flick'
> > Cc: [email-masked]
> > Subject: RE: draft-ietf-hubmib-etherif-mib-v2-02.txt
> > 
> > 
> > Lynn, John,
> > 
> > As I am on the road, I cannot look into my archives to what 
> > the previous
> > question about dot3PauseLinkDelayAllowance was bout. I 
> > vaguely remember that
> > it was about what units to use and the answer was that IEEE 
> chose this
> > because of scaling reasons. I can imagine how someone can use 
> > this object to
> > finetune/debug the extreme conditions of the PAUSE mechanism, 
> > though I agree
> > it looks like a IEEE technicality.
> > 
> > SO, anybody is loudely protesting to the proposal of taking 
> > this object out
> > of the MIB at the first occasion?
> > 
> > Dan
> > 
> > 
> > > -----Original Message-----
> > > From:	Kubinec, Lynn [SMTP:[email-masked]]
> > > Sent:	Mon February 01 1999 22:54
> > > To:	'John Flick'
> > > Cc:	[email-masked]
> > > Subject:	RE: draft-ietf-hubmib-etherif-mib-v2-02.txt
> > > 
> > > Ah...thanks for this work.  I was focussed on finding something 
> > > that affected the pause functionality and missed these references
> > > entirely.  
> > > 
> > > I guess I'm wondering why pause quanta isn't a "manageable" 
> > > object...is it because it's not in the IEEE spec or have we
> > > discussed this and I was on another planet?  
> > > 
> > > Lynn
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: John Flick [mailto:[email-masked]]
> > > > Sent: Monday, February 01, 1999 2:33 PM
> > > > To: Kubinec, Lynn
> > > > Cc: [email-masked]
> > > > Subject: RE: draft-ietf-hubmib-etherif-mib-v2-02.txt
> > > > 
> > > > 
> > > > Kubinec, Lynn writes:
> > > >  > Hi all,
> > > >  > 
> > > >  > I received a question regarding one of the MIB objects in
> > > >  > the etherif MIB.  I can't answer it, so I'm looking to the
> > > >  > group for help.  The object is the 
> dot3PauseLinkDelayAllowance.
> > > >  > 
> > > >  > Anyone have any idea what this REALLY is?  Is it the 
> > pause quanta
> > > >  > multiplied by 512?
> > > >  > 
> > > >  > I've checked the 1998 version of IEEE 802.3 which includes 
> > > >  > 802.3x and y (1997).  The only reference to 
> LinkDelayAllowance
> > > >  > is in the management section (30.3.4.1).  In the Annex (31B),
> > > >  > the Pause function's parameter is pause quanta.
> > > >  > 
> > > >  > Any enlightenment greatly appreciated.  Thanks!
> > > >  > 
> > > >  > Lynn
> > > > 
> > > > The only mention of the link delay allowance in the Annex 
> > is at the
> > > > end of 31B.3.7:
> > > > 
> > > >     "In addition to DTE and MAC Control delays, system designers
> > > >     should take into accoutn the delay of the link segment when
> > > >     designing devices that implement the PAUSE operation 
> > (see Clause
> > > >     29)." 
> > > > 
> > > > Tables in clause 29 have maximum round trip delay bit times for
> > > > various types of cabling.  Clause 42 has similar information for
> > > > Gigabit.
> > > > 
> > > > The annex doesn't specifically say how the pause function 
> > is supposed
> > > > to use this information, or why it may be interesting from a
> > > > management point of view.  I'll let Dan handle that, 
> > since he was the
> > > > one arguing to keep this object when I wanted to nuke it :-)
> > > > 
> > > > John
> > > > 
> > 
> 

Subject: Re: 802.3 LinkDelayAllowance
From: [email-masked]
To: Andrew Smith <[email-masked]>
Cc: 'Geoff Thompson' <[email-masked]>, Steve Haddock <[email-masked]>, 'Howard Frazier' <[email-masked]>
Date: Wed, 3 Feb 1999 11:06:32 -0800

Andrew-

The history of link delay in 802.3 is rich with tradition. In CSMA/CD times
it was carefully bounded to values well below the threshold that software
folks cared about for the purposes of mainting the CSMA/CD access method
(i.e. total delay in a segment had to be less than 1/2 slot time).

Full-Duplex blew that away. You don't care anymore from a layer 1-2 point
of view EXCEPT for flow control. You need to allow for the number of bits
buffered in the medium and the physical delays in the PHYs when you do your
threshold calculations for flow control.

There are delay parameters in the PHY specs. There is an escape clause that
you do not have to meet these for full-duplex but they at least set the
norm for that case. Media delays are also specificed in the standard either
or a per link or a per meter basis. That makes it all something that can be
calculated.

Hope this helps,

Geoff

At 10:11 AM 2/2/99 -0800, Andrew Smith wrote:
>Dear 802.3 gurus,
>
>A question came up while updating the IETF Ethernet MIB for gigabit. Seems
>to me like LinkDelayAllowance is a parameter that an implementation might
>choose as a local matter based on particular physical cable characteristics
>but hardly one that needs to be SETable by a remote manager.
>
>Any insight into the intended use of this parameter? Do the different 802.3
>cable types/PMDs include recommendations for the values to use for this
>parameter?
>
>Thanks,
>
>Andrew
>
>
>-----Original Message-----
>From: Dan Romascanu [mailto:[email-masked]] 
>Sent: Tuesday, February 02, 1999 7:58 AM
>To: Kubinec, Lynn; 'John Flick'
>Cc: [email-masked]
>Subject: RE: draft-ietf-hubmib-etherif-mib-v2-02.txt
>
>
>Lynn, John,
>
>As I am on the road, I cannot look into my archives to what the previous
>question about dot3PauseLinkDelayAllowance was bout. I vaguely remember
that
>it was about what units to use and the answer was that IEEE chose this
>because of scaling reasons. I can imagine how someone can use this object
to
>finetune/debug the extreme conditions of the PAUSE mechanism, though I
agree
>it looks like a IEEE technicality.
>
>SO, anybody is loudely protesting to the proposal of taking this object out
>of the MIB at the first occasion?
>
>Dan
>
>
>> -----Original Message-----
>> From:	Kubinec, Lynn [SMTP:[email-masked]]
>> Sent:	Mon February 01 1999 22:54
>> To:	'John Flick'
>> Cc:	[email-masked]
>> Subject:	RE: draft-ietf-hubmib-etherif-mib-v2-02.txt
>> 
>> Ah...thanks for this work.  I was focussed on finding something 
>> that affected the pause functionality and missed these references
>> entirely.  
>> 
>> I guess I'm wondering why pause quanta isn't a "manageable" 
>> object...is it because it's not in the IEEE spec or have we
>> discussed this and I was on another planet?  
>> 
>> Lynn
>> 
>> 
>> > -----Original Message-----
>> > From: John Flick [mailto:[email-masked]]
>> > Sent: Monday, February 01, 1999 2:33 PM
>> > To: Kubinec, Lynn
>> > Cc: [email-masked]
>> > Subject: RE: draft-ietf-hubmib-etherif-mib-v2-02.txt
>> > 
>> > 
>> > Kubinec, Lynn writes:
>> >  > Hi all,
>> >  > 
>> >  > I received a question regarding one of the MIB objects in
>> >  > the etherif MIB.  I can't answer it, so I'm looking to the
>> >  > group for help.  The object is the dot3PauseLinkDelayAllowance.
>> >  > 
>> >  > Anyone have any idea what this REALLY is?  Is it the pause quanta
>> >  > multiplied by 512?
>> >  > 
>> >  > I've checked the 1998 version of IEEE 802.3 which includes 
>> >  > 802.3x and y (1997).  The only reference to LinkDelayAllowance
>> >  > is in the management section (30.3.4.1).  In the Annex (31B),
>> >  > the Pause function's parameter is pause quanta.
>> >  > 
>> >  > Any enlightenment greatly appreciated.  Thanks!
>> >  > 
>> >  > Lynn
>> > 
>> > The only mention of the link delay allowance in the Annex is at the
>> > end of 31B.3.7:
>> > 
>> >     "In addition to DTE and MAC Control delays, system designers
>> >     should take into accoutn the delay of the link segment when
>> >     designing devices that implement the PAUSE operation (see Clause
>> >     29)." 
>> > 
>> > Tables in clause 29 have maximum round trip delay bit times for
>> > various types of cabling.  Clause 42 has similar information for
>> > Gigabit.
>> > 
>> > The annex doesn't specifically say how the pause function is supposed
>> > to use this information, or why it may be interesting from a
>> > management point of view.  I'll let Dan handle that, since he was the
>> > one arguing to keep this object when I wanted to nuke it :-)
>> > 
>> > John
>> > 
>
|=========================================|
| Geoffrey O. Thompson                    |
| Chair IEEE 802.3                        |
| Nortel Networks, Inc.  M/S SC5-02       |
| 4401 Great America Parkway              |
| P. O. Box 58185                         |
| Santa Clara, CA 95052-8185  USA         |
| Phone: +1 408 495 1339                  |
| Fax:   +1 408 988 5525                  |
| E-Mail: [email-masked]  |
| Please see the IEEE 802.3 web page at   |
 http://grouper.ieee.org/groups/802/3/index.html

---

From: "Kubinec, Lynn" <[email-masked]>
Date: Wed, 3 Feb 1999 17:48:07 -0600

Hi Andrew, Geoff,

What a very cool and excellent answer.  Thank you.

All, 

I propose that we nix the PauseLinkDelayAllowance object 
entirely from the Etherif MIB...anyone else?

If we're going to manage something, I would think Pause Quanta 
would be the thing to manage and I can see where administrators 
would like to play with the value.  I also see where this
lies "above" the etherif MIB, but do we want to spread Pause 
Control management out across the layers or just cram it all in 
here?  I guess the problem actually is that this object goes 
"with" the _ethernet_ interface, on a host, bridge, router,
what ever.  So if we put Pause Quanta in the correct "layer"
MIB, a network admin would have to look in MIB A for the object 
on a host which is connected to a bridge, and in MIB B for the
same object on the connected bridge.  I'd think we'd want
both ends of the wire to look in the same MIB to set the 
parameter.

Anyone?

Lynn

> From: Andrew Smith [mailto:[email-masked]]
> Sent: Wednesday, February 03, 1999 4:35 PM
> To: [email-masked]'
> Cc: [email-masked]'
> Subject: LinkDelayAllowance object?
> 
> 
>

---

From: Andrew Smith <[email-masked]>
Date: Wed, 3 Feb 1999 18:55:26 -0800

Lynn,

It's slightly more tricky than that even: a switch that wants to assert
flow-control back onto one of its input links is probably doing it because
its buffers/queues are full. In most switches these days (output buffered),
it is going to be very hard to find an appropriate pause period on a
per-input-port basis: the congested resource is likely related to an
*output* port that is itself backed up so the pause period ought to be
related somehow to where the input link's traffic is actually going - that's
a difficult problem. And, if the output port is backed up due to its being
flow-controlled in turn by the next switch down the line, then who is to
know what pause quantum will be appropriate for its input port?

IEEE 802 recently attempted to study this problem but decided to disband the
study group, in part because the problem was getting a bit intractable.

Andrew

> Sent: Wednesday, February 03, 1999 3:48 PM
> To: 'Andrew Smith'; [email-masked]'
> Subject: RE: LinkDelayAllowance object?
> 
> 
> Hi Andrew, Geoff,
>

---

From: "Kubinec, Lynn" <[email-masked]>
Date: Thu, 4 Feb 1999 20:15:22 -0600

Hi Andrew,

As always, point nicely made.  My suggestion regarding
managing Pause Quanta is summarily withdrawn :-)  

I still would like to see the LinkDelayAllowance object
be removed.

Lynn

> Sent: Wednesday, February 03, 1999 8:55 PM
> To: Kubinec, Lynn; [email-masked]'

---

From: "Paul Moran" <[email-masked]>
Date: Mon, 8 Feb 1999 09:28:36 +0000

Just before this email thread started, I was looking at this MIB table with a
view to implementing
it in a switch.  Firstly I could not understand the LinkDelayAllowance object.
Having guessed roughly
what it was trying to control, I could not see why I would want network managers
changing it. I would
have been happier with an object to configure the 'pause quanta', but even then,
I considered that
it would only be useful for debugging - not relevant for network managers.

I would drop the LinkDelayAllowance object.

Paul J Moran
Consultant Engineer
3Com

---

From: Andrew Smith <[email-masked]>
Date: Mon, 8 Feb 1999 11:02:26 -0800

Nuke it!

Andrew

> Sent: Monday, February 08, 1999 12:41 AM
> To: 'Kubinec, Lynn'; 'Andrew Smith'; [email-masked]'
> The proposal is getting rid of the PauseLinkDelayAllowance 
> object is formaly
> on the table. 
> 
> Going once...
> 
> Dan
> 
> > Sent:	? ?????? 05 1999 4:15