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

Re: Unified PMD vs. Unified PHY




Pankaj,

I am not sure where the 576 octets figure comes from.  Can you give us some
information on where that comes from?  I have been told that UUNet supports
over 12K datagrams.

Thank you,
Roy Bynum

----- Original Message -----
From: Pankaj Kumar <pkumar@xxxxxxxxxx>
To: Roy Bynum <rabynum@xxxxxxxxxxxxxx>
Cc: Benjamin J. Brown <bebrown@xxxxxxxxxxxxxxxxxx>; 802.3ae
<stds-802-3-hssg@xxxxxxxx>
Sent: Wednesday, March 15, 2000 12:25 PM
Subject: Re: Unified PMD vs. Unified PHY


> Roy
>    I guess at present the IP  datagrams on internet is default maximum
size of
> 576 octets. From this information, an average of  might be 500 bytes ( in
place
> of 400) can be assumed for overhead recovery that can be achieved with
frame
> stuffing  with IPG compression SONET overheads.
>    It is always appropriate to sent the small datagram to avoid
unnecessary
> fragmentation at intermediate gateways.
>
> Pankaj
>
> Roy Bynum wrote:
>
> > Ben,
> >
> > The expense in transfer rate is an addtional 3% above the ~4% of the
SONET
> > framing.  This makes the total bandwidth expense of the Unified PHY
close to
> > 7%.  This is almost half of the overhead cost of ATM.
> >
> > With the proposal of IPG compression in the PHY, most of the ~4%
overhead of
> > the SONET framing can be recovered.  The overhead recovery will be more
> > effective with small frames than with large frames, but I believe that
it
> > will average out.  At present, I have been told that the average IP
datagram
> > on the Internet is 380 bytes.  This is the same as it was two years ago,
so
> > it does not seem to be shifting very much.  From this information, an
> > average of 400 bytes can be somewhat safely used to determine the
average
> > overhead recovery that can be achieved with frame stuffing as proposed
by
> > Nortel and Lucent.  With a reduction of the IPG by 10 bytes, using an
> > average 400 byte frame (with current IPG, 420bytes), 2.3% average
overhead
> > recovery can be added to the MAC transfer rate.
> >
> > With IPG recovery using frame stuffing, the overhead cost of the WAN phy
> > becomes ~1.7%. Compared to the ~7% overhead of the 64B/66B proposal,
that is
> > a difference of 6.3%.   This makes the cost of the unifed PHY at least
6.3%
> > greater than the seperate WAN PHY.  I think that the original compromise
and
> > the objectives as stated are correct, there needs to be seperate LAN and
WAN
> > PHYs.
> >
> > Thank you,
> > Roy Bynum
> >
> > ----- Original Message -----
> > From: Benjamin J. Brown <bebrown@xxxxxxxxxxxxxxxxxx>
> > To: 802.3ae <stds-802-3-hssg@xxxxxxxx>
> > Sent: Monday, March 13, 2000 8:50 AM
> > Subject: Re: Unified PMD vs. Unified PHY
> >
> > >
> > >
> > > Roy,
> > >
> > > Let's please keep this on the reflector so everyone can follow
> > > along with the discussion. This way, others with similar concerns
> > > or questions won't be kept in the dark.
> > >
> > > A question has been raised regarding how tightly coupled the
> > > XAUI and 64b/66b encodings are or need to be. Several people,
> > > including me, have voiced the opinion that there shouldn't
> > > be any requirement that 64b/66b uses the encoding of XAUI.
> > >
> > > As for the expense in transfer rate, I'm a little confused. I
> > > believe Howard Frazier pointed out that over WAN, the 64b/66b
> > > encoding scheme is somewhat less efficient (3%?) than a
> > > scrambled encoding. I agree this is an issue worth discussing
> > > but it is a PCS issue, not a PMD one.
> > >
> > > Look at a serial PHY. From the MAC to the PCS is an XGMII.
> > > Some implementations may choose to extend this XGMII using
> > > XAUI but this interconnect is optional. The PCS should not
> > > require any features of the XAUI. The PCS encodes the MAC
> > > data from the XGMII then this data is serialized and driven
> > > onto the fiber. The encoding scheme within the PCS is the
> > > factor which determines the required baud rate on the fiber.
> > >
> > > Because we chose to make as an objective the support of a
> > > WAN compatible PHY, we chose a baud rate of 9.95328 G for
> > > the PMA/PMD. To share this PMA/PMD with serial LAN solutions
> > > (in order to reduce the number of discreet PMA/PMDs in the
> > > standard), we'd like to choose an encoding scheme for the
> > > LAN which shares this baud rate (or something close enough
> > > that works). We're kind of working this problem backwards.
> > >
> > > We'd also like to have a common encoding scheme (or as
> > > common as possible) between the WAN and the LAN. For both
> > > of these reasons, we're looking at 64b/66b and scrambling.
> > > Both of these can support a common baud rate necessary to
> > > reduce the number of PMA/PMDs and a common encoding scheme
> > > necessary to support the results of Jonathan's survey.
> > >
> > > Ben
> > >
> > > Roy Bynum wrote:
> > > >
> > > > Ben,
> > > >
> > > > Gb-Mtr is an acronym that I created because I quickly got tired of
> > > > repeatedly spelling out "Gigbit MAC transfer rate".  The real
question
> > was
> > > > not relative to the baud rate of a LAN PMD vs a WAN PMD, but the
> > confusion
> > > > that has been introduced by the effort to "unify" the PHY.
XAUI/64B66B
> > > > encoding makes XAUI a requirement, and efforts to reduce the PMD
rate to
> > a
> > > > single common is going to be very expensive in transfer rate.  By
> > abandoning
> > > > the "Hari" based 8B10B block encoding, the frame stuffing proposals
by
> > > > Nortel and Lucent give the ability recover much if not all of the
MAC
> > > > transfer rate.
> > > >
> > > > Johnathan has been using the object of having common PMDs as the
reason
> > for
> > > > supporting a PHY that provides a specific vendor the ability to
maintain
> > the
> > > > 8B10B to be required at the MAC chip.  The issue is to segregate the
> > issue
> > > > of common PMDs from that of a common PHY, so that the requirement
for
> > 8B10B
> > > > can be released.
> > > >
> > > > Thank you,
> > > > Roy Bynum
> > > >
> > > > ----- Original Message -----
> > > > From: Benjamin J. Brown <bebrown@xxxxxxxxxxxxxxxxxx>
> > > > To: 802.3ae <stds-802-3-hssg@xxxxxxxx>
> > > > Sent: Sunday, March 12, 2000 3:27 PM
> > > > Subject: Re: Unified PMD vs. Unified PHY
> > > >
> > > > >
> > > > >
> > > > > Roy,
> > > > >
> > > > > I realize you asked your question to Jonathan, but if you don't
> > > > > mind I'll try an answer to this.
> > > > >
> > > > > In support of the WAN, the serial PMDs (and PMAs) must support
> > > > > a 9.95328 Gbaud rate. I think it was fairly clear from early
> > > > > on that using an 8b10b encoding for the LAN would require a
> > > > > 12.5 Gbaud rate and that the PMA/PMD for LAN & WAN could not
> > > > > be identical (as the WAN PMA/PMD doesn't simply scale up in
> > > > > baud rate).
> > > > >
> > > > > I believe that is the idea behind the 64b/66b and SLP proposals
> > > > > as these encodings require 10.3125 and 10.000 Gbaud rates,
> > > > > respectively. These baud rates are within the range of current
> > > > > WAN PMA/PMDs to achieve. This means for the serial PMA/PMDs,
> > > > > a single solution can be generated (or perhaps 2 - longwave
> > > > > and shortwave) and dialed with an appropriate oscillator to
> > > > > support the WAN rate (9.95328 Gbaud) or the LAN rate (10.3125
> > > > > or 10.000 Gbaud).
> > > > >
> > > > > The PMA/PMD cares little about the content of the data going
> > > > > onto or coming off of the fiber. The encoding affects the baud
> > > > > rate in order to account for overhead.
> > > > >
> > > > > BTW: What is a Gb-Mtr?
> > > > >
> > > > > Ben
> > > > >
> > > > > Roy Bynum wrote:
> > > > > >
> > > > > > Johnathan,
> > > > > >
> > > > > > I was intending to ask you why you did not ask about unified
PMDs
> > > > > > separate from a unified PHY as part of your survey but did not
get a
> > > > > > chance.  At the 10GEA technical meeting you were very adamant
about
> > > > > > getting consensus for a small set of PMDs.  I agree that having
a
> > small
> > > > > > group of PMDs is preferable.  Having a unified PHY in order to
have
> > a
> > > > > > small set of PMDs may not be preferable.
> > > > > >
> > > > > > The cost of the unified PHY, as presented, so far has been very
high
> > in
> > > > > > the form of lost transfer rate.  As it is, the unified PHY, as
> > > > > > presented, does not meet the objective to have a 10.000 Gigabit
MAC
> > > > > > data transfer rate (Gb-Mtr).  Separate PHYs, LAN and WAN do meet
the
> > > > > > objectives.  Additionally, one of the scramble encoded WAN PHY
> > > > > > presentations was able to achieve an average 10.000 Gb-Mtr
transfer
> > rate
> > > > > > by using IPG compression, which can be inferred to meet the
10.000
> > > > > > Gb-Mtr objective in addition to the 9.548 Gb-Mtr objective.
> > > > > >
> > > > > > A unified PMD set can support the block encoded LAN PHY and the
> > scramble
> > > > > > encoded WAN PHY, allowing both to meet the 10.000 Gb-Mtr
objective.
> > > > > > This will allow the PMD people to concentrate on the
technologies of
> > the
> > > > > > PMDs with the consideration of a signaling range to support both
> > PHYs.
> > > > > > It will also simplify the marketing of 10GbE by reducing the
> > confusion
> > > > > > about distances and fiber types.
> > > > > >
> > > > > > As was demonstrated in some of the previous presentations (SUPI
and
> > OIF
> > > > > > SERDES), it is possible to have unified PMDs without having a
> > unified
> > > > > > PHY.  If the question had been asked, would it have made a
> > difference to
> > > > > > separate the issues?  If they are separate issues, as a I
believe
> > they
> > > > > > are, then should the survey be redone with that segregation?
Would
> > this
> > > > > > have put less pressure on group to have a unified PHY and
changed
> > the
> > > > > > scaling of the responses?
> > > > > >
> > > > > > Thank you,
> > > > > > Roy Bynum
> > > > >
> > > > >
> > > > > --
> > > > > -----------------------------------------
> > > > > Benjamin Brown
> > > > > Router Products Division
> > > > > Nortel Networks
> > > > > 1 Bedford Farms,
> > > > > Kilton Road
> > > > > Bedford, NH 03110
> > > > > 603-629-3027 - Work
> > > > > 603-629-3070 - Fax
> > > > > 603-798-4115 - Home
> > > > > bebrown@xxxxxxxxxxxxxxxxxx
> > > > > -----------------------------------------
> > >
> > >
> > > --
> > > -----------------------------------------
> > > Benjamin Brown
> > > Router Products Division
> > > Nortel Networks
> > > 1 Bedford Farms,
> > > Kilton Road
> > > Bedford, NH 03110
> > > 603-629-3027 - Work
> > > 603-629-3070 - Fax
> > > 603-798-4115 - Home
> > > bebrown@xxxxxxxxxxxxxxxxxx
> > > -----------------------------------------
>