Re: [8023-CMSG] Proposed Upper Layer Compatibility Objective
Jonathan,
Thanks for responding. You make very good points. I am looking to the
"old salts" of IEEE to ensure we have the right set of unambiguously
worded objective for success (this is not my forte). Below is another
possible approach (confine the objective to applying only to the target
space, of which we still need to clear definition).
"The objective is to define 802.3 congestion control support that (when
utilized within the bounds of {the target layer 2 subnets and operating
environments 'needs definition'} ), will, at a minimum, show no
measurable decrease in the performance of the existing upper layer
protocols and flow/congestion control mechanisms normally utilized
within {the target subnets and environments 'definition needs to include
802.3 full-duplex link technology and physical distance limitations'}. A
further objective is to facilitate the improved performance of some
existing and emerging protocols utilized within {the target spaces}."
I was also hoping to solicite feedback on the general sentiments within
the CMSG as to whether or not we need such an objective.
Gary
-----Original Message-----
From: owner-stds-802-3-cm@LISTSERV.IEEE.ORG
[mailto:owner-stds-802-3-cm@LISTSERV.IEEE.ORG] On Behalf Of Jonathan
Thatcher
Sent: Thursday, May 13, 2004 10:48 AM
To: STDS-802-3-CM@LISTSERV.IEEE.ORG
Subject: Re: [8023-CMSG] Proposed Upper Layer Compatibility Objective
Gary,
One difficulty is the ambiguity of the words "degrade the operation"
(any other words in the same position with the same general meaning will
have the same problem).
We are going to have to have a working definition that provides
guidance. Two extreme interpretations might help explain the problem.
1. I, XYZ, interpreted "degrade the operation" to mean that there is no
measurable decrease in performance of the protocol, even if operating at
a lowest priority. 2. I, ABC, interpreted "degrade the operation" to
mean that as long as we can turn off CM and run like we do today, we
have met the objective, no matter how well or how poorly any specific
upper layer protocol operates with CM.
XYZ and ABC can both raise their hands supporting the objective. But,
when the work begins, and decisions are made, both can simultaneously
cry foul.
It might be the case that before we can get our arms around this, we
need specific and detailed information and analysis about what can go
wrong (e.g. PAUSE working at odds with TCP/IP) and why. It is difficult
to know what is acceptable and what is not acceptable when we don't know
precisely what what is.
jonathan
-----Original Message-----
From: owner-stds-802-3-cm@LISTSERV.IEEE.ORG
[mailto:owner-stds-802-3-cm@LISTSERV.IEEE.ORG]On Behalf Of McAlpine,
Gary L
Sent: Wednesday, May 12, 2004 1:45 PM
To: STDS-802-3-CM@LISTSERV.IEEE.ORG
Subject: [8023-CMSG] Proposed Upper Layer Compatibility Objective
My A.R. from last meeting (thank you Ben).
Here's a first shot at a Upper Layer Compatibility objective:
The objective is:
"To define 802.3 congestion control support that, at a minimum, will do
nothing to degrade the operation of existing upper layer protocols and
flow/congestion control mechanisms, but has the explicit goal of
facilitating the improved operation of some existing and emerging
protocols, over 802.3 full-duplex link technology."
If we can narrow the scope and still make it meaningful, I'm all for it.
I have attached RFC3168 (on ECN) as a reference. It contains a very good
overview of congestion control at the TCP and IP layers. I would also
consider this and DiffServ as examples of existing ULPs we would want to
do our part to improve the operation of. IMO, what we can do at the
802.3 level to better support these will also provide the support we
need for improved operation of some emerging protocols such as iSCSI and
RDMA.
Gary <<rfc3168.txt>>