[rbridge] draft protocol-10 WGLC Maximum Bridge Transit Delay

[Donald Eastlake]

Hi Jim,

On Mon, Dec 1, 2008 at 9:15 AM, James Carlson <james.d.carlson at sun.com> wrote:
> Donald Eastlake writes:
>> > Do modern bridges actually _implement_ such a feature, or do they just
>> > have a knob labeled "Maximum Bridge Transit Delay" that's connected to
>> > nothing underneath?
>>
>> It is my impression that low end 802.1D bridges don't implement this
>> but mid and high end 802.1Q bridges do. Typically, when a frame is
>> received, a control block is created with the VLAN, priority, time of
>> receipt, and other control information. When a frame is de-queued for
>> transmission, the time is checked and frame discarded if it is too
>> old. This time check doesn't need to be, and probably isn't, extremely
>> accurate.
>
> Under what conditions would that be expected to happen?

Actually, I think I may have misstated what happens as you would want
old frames discarded that were just sitting around in a queue, not
just when they were de-queued.

All you need is enough higher priority frames and low priority ones
could be queued forever even with no link ever going down and no flow
control impediments.

> I suspect that one good reason to avoid bothering with such a feature
> on high-end switches is that the amount of buffering required to reach
> a 1 second delay at high line rates becomes prohibitive -- in other
> words, you'll ordinarily drop on queue entry well before that happens
> in all but pathological cases, so why bother caring?

Hummm, it's not clear to me what the resolution of the maximum transit
delay is... although 1 second is the default, the resolution could be
small allowing it to be set to some number of milliseconds or
something...

As above, you could have a stream of, say, 1 Gbps higher priority
frames going from port 1 to port 3 and one lower priority frame for
port 3 that drifts in port 2 and this poor low priority frame could
just sit in a queue for days and then pop out due to a hiccup in the
high priority stream. I won't argue if you want to call that
pathological but it doesn't seem good that it could happen.

>> > I'm inclined to say "no" to this, just on the basis that I cannot see
>> > how it would serve any real purpose.  It looks like a spec for the
>> > sake of a spec.
>>
>> In bridges, I think it is required to back up the assurances of
>> Spanning Tree Protocol. I think bridges also flush the output queue
>> and any input queue associated with a port when the port goes down.
>> Generally, it seems like good hygiene not to keep a frame for a long
>> time and then release it...

(As I recall, the 802.1 bridging model does not really admit that
input queues can exist so any frame in an input queue is logically
considered not to have been received yet by the bridge...)

> We're not using STP here, though, so we don't need to back up its
> assurances.

The specific provisions in 802.1D-2004 include :
"6.3.6 Frame lifetime
The MAC Service mandates an upper bound to the transit delay
experienced for a particular instance of
communication. This maximum frame lifetime is necessary to ensure the
correct operation of higher layer
protocols. ..."

"7.1.1 Relay
A MAC Bridge relays individual MAC user data frames between the
separate MACs of the bridged LANs
connected to its Ports. The functions that support relaying frames and
maintain QoS are as follows:
...
l) Frame discard to ensure that a maximum bridge transit delay is not
exceeded (6.3.6).
..."

"7.7.3 Queuing frames
...
A frame queued for transmission on a Port shall be removed from that
queue if that is necessary to ensure
that the maximum bridge transit delay (6.3.6, Table 7-3) will not be
exceeded at the time at which the frame
would subsequently be transmitted.
..."

Similar provisions appear in 802.1Q-2005.

> As for avoiding a too-old release, I don't think that's easy to avoid
> with modern hardware due to the funky 802 flow control mechanism.  If
> the other end is having trouble, you can end up with a really old
> frame caught in your transmission craw.  It'd require some fancy
> footwork in most implementations I've seen to detect that sort of edge
> case, reset, and restart.
>
>> It would certainly be easy enough to make this a SHOULD rather than
>> being mandatory the way it is in 802.1, not that people seem to pay
>> that much attention to what is mandatory in 802.1. But perhaps it
>> really isn't necessary for RBridges... Anyone else have an opinion on
>> this.
>
> That 'one second delay' smells to me too much like the old IP TTL
> specification, and likely dates back to the same rules of thumb.
>
> I think that SHOULD is a fairly strong statement; it means that
> implementors who choose not to implement that feature need to have a
> clear explanation of why they don't, if they're going to try to follow
> the spirit of the RFC.  I don't think it ought to be a SHOULD unless
> it's something that's required for interoperability in most cases, but
> can be avoided in a few.  As 2119 says:
>
> 3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>   may exist valid reasons in particular circumstances to ignore a
>   particular item, but the full implications must be understood and
>   carefully weighed before choosing a different course.
>
> Do RBridge implementors really need to weigh the pros and cons of
> implementing the delay time check in order to achieve
> interoperability?
>
> MAY is closer to the intent of saying, "here's something that's common
> in this field and that may be helpful in an implementation, but that
> is not known to be required for the sake of interoperability of
> RBridges."

Well, I'm OK with saying MAY. Since this is described in the 802.1
standards as being in the port output queue behavior, and since we now
incorporate that by reference unless we say otherwise, one could argue
that it is mandatory under the current draft. Unless people weigh in
with other opinions, I'll change it to MAY.

> James Carlson, Solaris Networking              <james.d.carlson at sun.com>
> Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
> MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-634-2066 (home)
 155 Beaver Street
 Milford, MA 01757 USA
 d3e3e3 at gmail.com