Re: [RE] Compatibility with 802 and why the study group is not yet a task force

["Solomon, Yoram" <yoram@xxxxxx>]

Title:

I fully agree. We seem to be focused on the solution before defining the problem.  I would like for us to work on a problem definition in Austin.

 

Regards,

 

Yoram.

 

---

From: owner-stds-802-3-re@IEEE.ORG [mailto:owner-stds-802-3-re@IEEE.ORG] On Behalf Of Beaudoin, Denis
Sent: Tuesday, April 12, 2005 6:42 AM
To: STDS-802-3-RE@LISTSERV.IEEE.ORG
Subject: Re: [RE] Compatibility with 802 and why the study group is not yet a task force

Two last elements to add to the list that may help RE move forward.

1) Define the problem! All I hear is how the solution will fix it, but when I see the latency diagram, the network only consists of less than 6% of the total delay. Why are we not focusing on the other 94% of the path delay?
2) Once the problem is defined, break the problem into appropriate classes like Audio Listening, Video Watching, Live Performances, Gaming, etc. It may be that the solution for most of the classes is already here, and the solution for a couple of the classes may need features to be added in 802.3.

I also agree with Arthur, the RE study group should use the IEEE RE reflector.

Regards Denis

Arthur Marris wrote:

Second attempt to get this sent to the email list

---

From: Arthur Marris
Sent: 11 April 2005 11:53
To: owner-stds-802-3-re@IEEE.ORG
Subject: Compatibility with 802 and why the study group is not yet a task force

Folks,

   On reviewing the Yahoo mailing list archive I saw an email asking why the compatibility with 802 criterion failed to get the necessary 75% approval in the 802.3 closing plenary session. In my view there are two reasons for this:

 

1) It was stated during the debate in the closing plenary by a study group member that no changes to the MAC or PHY may be necessary. If that is the case then what is the point of doing an 802.3 project? You need to give the 802.3 working group some idea of what it is that you want to do.

 

2) You failed to convince 802.1 that what you are proposing is compatible with their switching specs. The tutorial gave the impression that the purpose of the task force would be to standardize a mooted Firewire switch architecture in 802.1. This switch architecture requires a separate queue for RE traffic and is required to deliver frames at precise time intervals. Predictably this did not go down well in 802.1 and the 802.3 working group took notice of this.

 

  I also have the following observations to make

i) To see RE through as an 802.3 project you need to engage with the wider 802.3 working group. Using a Yahoo mailing list rather than this one does not help. If you want to know why people voted against the compatibility criterion ask on this mailing list. The vote to set up the study group was 41 to 7 so there is support for a task force and making changes to the 802.3 spec for RE. Don't squander this good will.

 

ii) You need a chair who is experienced in 802.3 policy and procedures. 

 

iii) You need to come up with a quantitative requirement for jitter and relative latency and justify it. I saw the figure of 10us mentioned on the Yahoo mailing list. This is ridiculously tight. An 802.3 voter who is experienced in VOIP pointed out to me that even 1ms is too tight when you consider that sound only travels one foot in a millisecond. Once you have this requirement nailed a lot else will fall into place.

 

iv) The sort of thing that would make sense for a task force would be to develop a mechanism for measuring link delay using MAC control frames so that time stamp information could be accurately interpreted. This is within the scope of 802.3 and clearly relevant to what you are trying to achieve with residential Ethernet.

 

Arthur.

 

-- 
Denis Beaudoin	  DMTS	 Texas Instruments   dbeaudoin@ti.com	972-480-3277