Re: Unified PMD vs. Unified PHY
Roy
This octet figure if from RFC 894. This RFC specifies IP datagram on an
ethernet. Here is ftp site for this RFC
ftp://ftp.isi.edu/in-notes/rfc894.txt
Pankaj
Roy Bynum wrote:
> 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
> > > > -----------------------------------------
> >