Re: [8023-CMSG] 802.1 presentation
Ben,
Thanks for the update and most of all thanks for standing up and
representing the thoughts of CMSG in foreign territory. I have a few
random comments:
1. Some L3 devices mark congestion, although the standards as written
imply that congestion notification is "an internet thing." At the very
least, we need to demonstrate the efficacy of these solutions for short,
fast networks. Obviously, we have the burden of proof for things we want
to define for bridges and for DTE MAC clients.
2. We can explore the idea of letting the end station adjust according
to the perceived round trip delay, but I suspect there will be two
problems: firstly, the end stations don't know what the delay "should
be" for optimal network performance; secondly, the approach may cause
divergent behavior as the "optimal" behavior is to increase number of
bytes in flight for longer RTT but (effectively) the only parameter that
the end station can use to adjust the network load is the number of
bytes in flight.
3. The network product (bandwidth * delay) is a very useful descriptor
for certain aspects of network design but isn't the only one. In
particular, the use of congestion notification is most effective for
networks where the bridge buffer memory is larger than the network
product but also where the RTT is not much more than the transport
window size. I think it can be shown that CN is particularly effective
in networks with a mixture of bridging devices with various buffering
and bandwidth characteristics.
4. I think that the time we spent looking at architectural and layering
issues has paid dividends. As the architecture group, 802.1 is most
sensitive to poorly thought-out proposals.
Hugh.
Benjamin Brown wrote:
> All,
>
> I gave the presentation to 802.1 this afternoon in Ottawa.
> It went well. They agreed to continue hearing proposals on
> the subject. Bob and Tony will discuss how the meeting
> logistics will work out.
>
> Layer 2/3 switches do this today, though it is not specified
> within 802.1.
>
> There were questions regarding the usefulness of using the
> intermediate bridges to indicate this information. It has already
> been shown that this is useful over smaller networks and less
> useful over larger networks. If the network is small (relative
> to the number of packets in flight), why not just have the receiving
> station flag congestion when it receives a packet that took longer
> to arrive than expected.
>
> To me, this means some kind of timing knowledge between
> end stations. First, a receiving station must know how long a
> packet should take to arrive from each destination. Second,
> stations must have a common time base in order to determine
> when that received packet has exceeded its expected flight
> time. Mick Seaman is pushing this idea so it would be interesting
> to pick his brain regarding where this is coming from.
>
> Mick wants us to specify the network power product for the
> networks that we feel are the most interesting. Bob told him that
> our major interest was with reducing discards and increasing
> throughput. A reduction in memory usage is merely a bonus.
> He said the power product is useful information since different
> values can point us in different directions. I don't understand
> this much. Thoughts and comments from those who do would
> be a useful discussion topic on this reflector (at least for me).
>
> We were apparently successful in bringing examples of possible
> solutions to show feasibility without trying to shove a solution
> down their throat. We apparently passed several litmus tests
> by not mentioning QOS and not suggesting a hop-by-hop
> solution. Several people told me after the presentation that they
> didn't know what to expect but didn't expect they were going to
> like it and instead were pleasantly surprised that we just want
> to solve a problem and don't really care how its done. We found
> one way but we're not married to it.
>
> Anyway, Bob might have other thoughts regarding the outcome
> of this meeting. If there are questions or comments on any of the
> above, please air them so we can talk about them.
>
> Thanks,
> Ben
>
>
>