Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [8023-CMSG] 802.1 presentation



Hi Ben,


        Thanks for promptly providing summary of your meeting with
802.1.
        Congratulations!

        So it seems:

        1. 802.1 appreciated the problem statement and its scope. And
they
           are willing to explore further.
        2. From Mick's suggestion for an alternate solution: it is clear
           that he is seriously thinking about the problem.
                - End-station based solution is a challenge, however
more
                  deatails may be needed for further discussion.
                - Need to look at the complexity.
                - However, serious consideration needs to be given.
        3. Bridges being congestion points, it may be easier to take
           action there.
        4. I am not sure about "Layer 2/3 switches do this today".
              - Is this regarding IP TOS - marking by L2 switches?

Thanks,
- Manoj



-----Original Message-----
From: owner-stds-802-3-cm@listserv.ieee.org
[mailto:owner-stds-802-3-cm@listserv.ieee.org] On Behalf Of Benjamin
Brown
Sent: Monday, October 04, 2004 12:59 PM
To: STDS-802-3-CM@listserv.ieee.org
Subject: [8023-CMSG] 802.1 presentation

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

--
-----------------------------------------
Benjamin Brown
178 Bear Hill Road
Chichester, NH 03258
603-491-0296 - Cell
603-798-4115 - Office
benjamin-dot-brown-at-ieee-dot-org
(Will this cut down on my spam???)
-----------------------------------------