[EFM] RE: Minutes of 10/30 FEC Conference Call
Forwarded from Frank Effenberger.
His message was bounced because it
contained the string "adddvertise" which
I have mispelled to let it pass through the
filters.
Howard
-------- Original Message --------
From: FEffenberger@xxxxxxxxxxxxxxxxx
To: Jonathan.Thatcher@xxxxxxxxxxxxxxxxxxxx, FEffenberger@xxxxxxxxxxxxxxxxx,
Larry.Rennie@xxxxxxx, elynskey@xxxxxxxxxxxxxx, Meir@xxxxxxxx,
piers_dawe@xxxxxxxxxxx, ariel.maislos@xxxxxxxxxxxxxxxx,
lior.khermosh@xxxxxxxxxxx, Vipul_Bhatt@xxxxxxxx, pat_thaler@xxxxxxxxxxx,
ajay@xxxxxxxxxxxx, limb@xxxxxxxxxxxx, masoud@xxxxxxxxxxxxxx,
Ali@xxxxxxxxxxxxxx
Cc: Jim.Wieser@nsc.com, stds-802-3-efm@ieee.org
Subject: RE: Minutes of 10/30 FEC Conference Call
Date: Wed, 30 Oct 2002 21:07:29 -0500
Jonathan,
What you say is a major shift from the Frame-FEC position.
That was not what was adddvertised by the proponents of frame-FEC.
Besides, who says that clause 36 stuff is going to be different for P2MP?
Layering, sir. Layering. Clause 36 was going to stay the same, according
to frame-FEC folks. This also was not adddvertised. This is a bait and
switch.
The issue that UNH has turned up is exactly the thing that Pat Thaler
had warned about - intentional errors may not be handled correctly by
every implementation, simply because errors are not effectively tested,
and their treatment is irregular.
I'm done.
Frank
-----Original Message-----
From: Jonathan Thatcher [mailto:Jonathan.Thatcher@xxxxxxxxxxxxxxxxxxxx]
Sent: Wednesday, October 30, 2002 8:25 PM
To: FEffenberger@xxxxxxxxxxxxxxxxx; Larry.Rennie@xxxxxxx;
elynskey@xxxxxxxxxxxxxx; Meir@xxxxxxxx; piers_dawe@xxxxxxxxxxx;
ariel.maislos@xxxxxxxxxxxxxxxx; lior.khermosh@xxxxxxxxxxx;
Vipul_Bhatt@xxxxxxxx; pat_thaler@xxxxxxxxxxx; ajay@xxxxxxxxxxxx;
limb@xxxxxxxxxxxx; masoud@xxxxxxxxxxxxxx; Ali@xxxxxxxxxxxxxx
Cc: Jim.Wieser@xxxxxxx
Subject: RE: Minutes of 10/30 FEC Conference Call
Frank,
There are no old P2MP parts. It is not possible to have interoperability
with existing parts. If it is not possible to have interoperability with
existing P2MP parts, it is not possible to fail to operate with existing
P2MP parts. There is no requirement for FEC based P2MP parts to interoperate
with P2P parts.
Therefore, 25% failure is not a failure at all. It clearly demonstrates that
it is possible to create a MAC that can interoperate with both FEC and
non-FEC hardware.
Besides, according to plan, Eric intends to look for a bit sequence that
will allow for all existing MACs to work. To me, this is overkill.
jonathan
| -----Original Message-----
| From: FEffenberger@xxxxxxxxxxxxxxxxx
| [mailto:FEffenberger@xxxxxxxxxxxxxxxxx]
| Sent: Wednesday, October 30, 2002 4:01 PM
| To: Jonathan Thatcher; FEffenberger@xxxxxxxxxxxxxxxxx;
| Larry.Rennie@xxxxxxx; elynskey@xxxxxxxxxxxxxx; Meir@xxxxxxxx;
| piers_dawe@xxxxxxxxxxx; ariel.maislos@xxxxxxxxxxxxxxxx;
| lior.khermosh@xxxxxxxxxxx; Vipul_Bhatt@xxxxxxxx;
| pat_thaler@xxxxxxxxxxx;
| ajay@xxxxxxxxxxxx; limb@xxxxxxxxxxxx; masoud@xxxxxxxxxxxxxx;
| Ali@xxxxxxxxxxxxxx
| Cc: Jim.Wieser@xxxxxxx
| Subject: RE: Minutes of 10/30 FEC Conference Call
|
|
| Interoperability means working with old parts.
| 25% failure rate is a failure.
| Until it hits 100%, you can't claim backward compatability,
| in my opinion.
| Frank.
|
| -----Original Message-----
| From: Jonathan Thatcher
| [mailto:Jonathan.Thatcher@xxxxxxxxxxxxxxxxxxxx]
| Sent: Wednesday, October 30, 2002 6:05 PM
| To: FEffenberger@xxxxxxxxxxxxxxxxx; Larry.Rennie@xxxxxxx;
| elynskey@xxxxxxxxxxxxxx; Meir@xxxxxxxx; piers_dawe@xxxxxxxxxxx;
| ariel.maislos@xxxxxxxxxxxxxxxx; lior.khermosh@xxxxxxxxxxx;
| Vipul_Bhatt@xxxxxxxx; pat_thaler@xxxxxxxxxxx; ajay@xxxxxxxxxxxx;
| limb@xxxxxxxxxxxx; masoud@xxxxxxxxxxxxxx; Ali@xxxxxxxxxxxxxx
| Cc: Jim.Wieser@xxxxxxx
| Subject: RE: Minutes of 10/30 FEC Conference Call
|
|
| The minutes were not clear. This does not mean 75% of frames.
| It means 75%
| of the 802.3z implementations passed frames without difficulty.
|
| Interpretation: it is not just possible, but likely that a
| MAC designed for
| P2MP can work with FEC or not without difficulty. The 25%
| proves that it is
| also possible to design a MAC for P2MP that will not work
| with FEC. But, why
| would one do that?
|
| jonathan
|
| | -----Original Message-----
| | From: FEffenberger@xxxxxxxxxxxxxxxxx
| | [mailto:FEffenberger@xxxxxxxxxxxxxxxxx]
| | Sent: Wednesday, October 30, 2002 2:12 PM
| | To: Larry.Rennie@xxxxxxx; elynskey@xxxxxxxxxxxxxx; Meir@xxxxxxxx;
| | Jonathan Thatcher; piers_dawe@xxxxxxxxxxx;
| | ariel.maislos@xxxxxxxxxxxxxxxx; lior.khermosh@xxxxxxxxxxx;
| | Vipul_Bhatt@xxxxxxxx; pat_thaler@xxxxxxxxxxx; ajay@xxxxxxxxxxxx;
| | limb@xxxxxxxxxxxx; masoud@xxxxxxxxxxxxxx;
| | FEffenberger@xxxxxxxxxxxxxxxxx; Ali@xxxxxxxxxxxxxx
| | Cc: Jim.Wieser@xxxxxxx
| | Subject: RE: Minutes of 10/30 FEC Conference Call
| |
| |
| | Larry,
| |
| | Quick question: How does a 75% success rate justify the claim of
| | interoperability?
| |
| | Frank.
| |
| |
| | -----Original Message-----
| | From: larry rennie [mailto:Larry.Rennie@xxxxxxx]
| | Sent: Wednesday, October 30, 2002 5:07 PM
| | To: Eric Lynskey; Meir Bartur; Jonathan Thatcher; Piers Dawe; Ariel
| | Maislos; lior khermosh; Vipul Bhatt; pat thaler; Ajay Gummalla; john
| | limb; Masoud Khansari; frank effenberger; Ali Abaye
| | Cc: jim
| | Subject: Minutes of 10/30 FEC Conference Call
| |
| |
| | FEC Conference Call
| | Wed Oct 30, 2002, 10-11:30AM PST
| |
| | Attendees
| |
| | Eric Lynsky, UNH
| | Meir Bartur, Zonu
| | Jonathan Thatcher, Worldwide Packets
| | Piers Dawe, Agilent
| | Ariel Maislos, Passave
| | Dora Zanaceen, Lucent
| | Larry Rennie (Chair) , National Semiconductor
| |
| | 1. CDR Testing. Eric's test show a CDR lock time of about
| | 800 bits for
| | the high BER (10E-4) condition versus about 100 bits for the no BER
| | condition. Agreed that the cause of the noise (attenuation
| | or MPN) did
| | not matter for a first order look at lock time. It was
| | pointed out that
| | even at 1000 bits, this is still a very small overhead on a
| | 250K bit or
| | so size burst. Still would be desirable to do the testing
| | with different
| | manufacturers components. If there is a spec on lock time,
| | how to do the
| | testing would be an issue.
| |
| | 2. MPN testing. Results from Zonu next week.
| |
| | 3. Legacy Testing. UNH working with Passave has done some legacy
| | testing to see if legacy nodes would receive an FEC
| formatted packet.
| | 75% success rate! Eric felt a change to the special FEC
| framing header
| | might fix the problem with the 25% that did fail.
| | Nevertheless, the 75%
| | success rate should be acceptable to satisfy interoperability claim.
| | Failure was the result of getting stuck in a false carrier state.
| |
| | 4. Where to put FEC in the standard was discussed. It would
| | be cleaner
| | to have a new Clause but another possibility is an
| addition to Clause
| | 36, but only if that Clause needs to changed anyway. Another
| | determining
| | factor is: does TF wants FEC to apply to P2P? This needs further
| | discussion and if it does then a new Clause for FEC is needed.
| |
| | 5. We need to put together a comprehensive FEC baseline for
| | the TF vote
| | in November. Latency time of FEC needs to be included.
| |
| | Action Items:
| |
| | 1. Eric to document CDR test methodology and test results for the
| | November meeting.
| | 2. Eric to document legacy test methodology and test results for
| | November meeting.
| | 3. Meir/Larry to document MPN test methodology and test results for
| | November meeting
| | 3. Ariel/Larry to do the FEC baseline presentation for
| | November meeting.
| | Note, this would be an updated version of previously
| presented frame
| | FEC presentations.
| | 4. Larry to do an FEC status report for November meeting.
| | 5. Larry to coordinate with Howard on where to add FEC.
| |
| | NOTE: Presentation submittal deadline is November 4, 2002.
| |
| | Larry
| |
| |
|