RE: [EFM] 1 Gbps != 999.9 Mbps
Barry,
It does not matter how much the overhead is as long as it is not in the
revenue data stream.
Thank you,
Roy Bynum
At 05:23 PM 9/27/01 -0700, O'Mahony, Barry wrote:
>Greetings,
>
>999.9 Mbps is within 100 ppm of 1 Gbps. Does the delivered bit rate need to
>be more precise than that? Suppose the OAM overhead is lower, such as the
>10K mentioned below, is that still too much?
>
>It seems to me that, if the requirement is to provide customers with the
>type of isochronous-type of service they can get from T1, DS[x], or ATM-type
>interfaces, with bit throughput guaranteed and drived from some precision
>clock hierarchy, then perhaps Ethernet is not the best choice to meet this
>requirement.
>
>Ethernet instead has tended to talk about "Classes" of networks that
>reference the raw bitrate, but don't really guarantee precise throughput,
>right?
>
>I would think that if a service was being sold as providing "1000BASE-x
>performance", most customers would comprehend what that was like. And
>certainly perceive it as a very attractive offering. Perhaps provisions
>could be made in the EFM specs. to add isochronous-type guarantees, but one
>needs to ask whether doing so would compromise the simplicity and
>flexibility that makes Ethernet so attractive for EFM in the first place.
>I'm just worried about the dangers of "feature creep".
>
>~~~~~~~~~~~~~~~~~~~~~~~~~~
>Barry O'Mahony
>Intel Architecture Labs
>Hillsboro, OR, USA
>tel: +1(503)264-8579
>barry.omahony@xxxxxxxxx
>barry.omahony@xxxxxxxxxxxx
>~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>-----Original Message-----
>From: Bob Barrett [mailto:bob.barrett@xxxxxxxxxxxxxxx]
>Sent: Thursday, September 27, 2001 4:11 PM
>To: Harry Hvostov; fmenard@xxxxxxxxxxxxxxx; 'Denton Gentry'
>Cc: 'stds-802-3-efm'
>Subject: RE: [EFM] 1 Gbps != 999.9 Mbps
>
>
>
>Harry et al
>
>yup, all the IP 'stuff' is payload as far as the demarcation point is
>concerned.
>
>The demarc is a PHY that carries packets at the end of the day. Some demarcs
>may be buried inside a bigger system, however, the standard must also cater
>for stand alone demarc devices. My expectation as a user would be that at
>the demarc the bandwidth was the same capacity as my enterprise MAC and PHY
>of the same spec.
>
>Would I miss 10k per second on a 1GE, I doubt it.
>
>Would my test gear pick it up on an end to end private circuit test, I don't
>know, anyone on the reflector tried this?
>
>Bob
>
> > -----Original Message-----
> > From: Harry Hvostov [mailto:HHvostov@xxxxxxxxxxxx]
> > Sent: 27 September 2001 17:41
> > To: 'fmenard@xxxxxxxxxxxxxxx'; 'Denton Gentry';
> > bob.barrett@xxxxxxxxxxxxxxx
> > Cc: 'stds-802-3-efm'
> > Subject: RE: [EFM] 1 Gbps != 999.9 Mbps
> >
> >
> > And how about the ICMP and IGMP traffic from the same CPE devices?
> >
> > Harry
> >
> > -----Original Message-----
> > From: Francois Menard [mailto:fmenard@xxxxxxxxxxxxxxx]
> > Sent: Thursday, September 27, 2001 6:05 AM
> > To: 'Denton Gentry'; bob.barrett@xxxxxxxxxxxxxxx
> > Cc: 'stds-802-3-efm'
> > Subject: RE: [EFM] 1 Gbps != 999.9 Mbps
> >
> >
> >
> > Or for that matter, what about ARP traffic unsolicited from my CPE
> > devices ?
> >
> > -=Francois=-
> >
> > -----Original Message-----
> > From: owner-stds-802-3-efm@majordomo.ieee.org
> > [mailto:owner-stds-802-3-efm@majordomo.ieee.org] On Behalf Of Denton
> > Gentry
> > Sent: September 26, 2001 3:12 PM
> > To: bob.barrett@xxxxxxxxxxxxxxx
> > Cc: stds-802-3-efm
> > Subject: [EFM] 1 Gbps != 999.9 Mbps
> >
> >
> >
> > > Service providers have a desire to offer a full 1GE service and not
> > > use any of it's bandwidth for OAM. The rule of conservation of
> > > bandwidth means the OAM needs to go somewhere other then in the
> > > bandwidth reserved for the 1GE payload. I take it as read that 100%
> > > utilisation of a 1GE is unlikely, but that is not the point. The point
> >
> > > is that service providers want to offer 1GE service period, not a
> > > 999.9Mbit service.
> >
> > Does the existence of the Mac Control PAUSE frame therefore make
> > Ethernet unsuitable for service providers?
> >
> > Denton Gentry
> > Dominet Systems