RE: Unified PMD vs. Unified PHY
Mike,
I guess my use of the word "application" was a little sloppy. I should have
been more precise and said the network transport layer (i.e. IP, IPX, etc.)
sets the packet size (obviously based on how the upper layer applications
are using the network).
What I was trying to highlight is that in normal LAN traffic, packets are
not coalesced into larger packets, but kept individually with an IPG between
each one. So, though a mixture of large and small frames may "average" to
400 bytes or so, the physical layer actually sees bimodal peaks of small and
large frames. What I was asking Roy was whether he was advocating some kind
of coalescing function to combine small frames into larger ones.
Clearer?
Walter Thirion
wthirion@xxxxxxxxxxxx
> -----Original Message-----
> From: Van Scherrenburg, Mike
> [mailto:Mike.Van.Scherrenburg@xxxxxxxxxxxxxxx]
> Sent: Thursday, March 16, 2000 2:22 PM
> To: 'stds-802-3-hssg@xxxxxxxx'
> Subject: Re: Unified PMD vs. Unified PHY
>
>
>
> Walter,
>
> Are you suggesting that what the application thinks is a
> packet size
> should be what the network physically uses as a packet size?
> I suspect that
> setting the physical (as in on a medium) packet size should
> be a network
> responsibility, involving issues of medium efficiency, and
> error performance
> (which an application should not have to worry about), and
> issues of mixing
> traffic types.(an application should not have to know what
> else is going
> over a channel, IMHO).
>
> For example, PPP limits MTU so that the response time of a remote
> terminal application will not be significantly degraded, by
> the network,
> should another data rate hungry application (say an ftp) also
> share the line
> (in the case of PPP, typically an analog modem link). The
> MTU limit would
> be drastically different if the "line" were at 1Mbit instead
> of 50Kbit. I
> don't see how we can fashion the ftp application, in this example, to
> dynamically change it's "logical" MTU (if it were determining
> the physical
> packet size), based on whether a remote terminal application
> also happens to
> be sharing the line, and simultaneously keep a sane world here.
>
>
>
> ----------
> From: Walter Thirion[SMTP:wthirion@xxxxxxxxxxxx]
> Sent: Wednesday, March 15, 2000 7:02 PM
> To: stds-802-3-hssg@xxxxxxxx
> Subject: RE: Unified PMD vs. Unified PHY
>
> Roy,
>
> What does the speed of the transmission system have to do
> with changing the
> packet size? Applications determine the packet size unless
> the transport is
> doing some kind of packet packing/blocking, etc.
>
> Walt
>
> -----Original Message-----
> From: Roy Bynum [mailto:rabynum@xxxxxxxxxxxxxx]
> Sent: Wednesday, March 15, 2000 8:53 PM
> To: Walter Thirion; stds-802-3-hssg@xxxxxxxx
> Subject: Re: Unified PMD vs. Unified PHY
>
>
> Walter,
>
> I agree with the bimodal nature of the data packet size
> spectrum.
> In very high bandwidth transmission systems these bimodel
> aspects tend to
> disapear. True, any one SONET/SDH frame will directly see these
> differences, which is why there still needs to be rate
> adaption between the
> MAC and the WAN PHY. However, over a period of time the
> transfer rate will
> average out. With at the average of 400 byte frames, frame
> stuffing and IPG
> compression will recover only a certain amount of bandwidth.
> The reason
> that I made this analysis is to be able to make some
> realistic comparisons
> between the various PCS/PMA options.
>
> Thank you,
> Roy Bynum
>
> ----- Original Message -----
> From: Walter Thirion
> To: 'stds-802-3-hssg@xxxxxxxx'
> Sent: Wednesday, March 15, 2000 7:23 AM
> Subject: RE: Unified PMD vs. Unified PHY
>
> Roy,
>
> I don't know how it affects your view of
> overhead, but the
> fact that the average packet is 400 bytes doesn't really mean
> anything. In
> most traffic studies I've seen, the traffic is somewhat
> bi-modal. There is a
> peak in the 64-100 byte range and another peak either just
> above 1k or at
> the max packet size, depending on where the traffic is
> measured. Though
> these two peaks may average to 400, there is, in fact, very
> little traffic
> in the middle range.
>
> Walt
>
>
>
> -----Original Message-----
> From: Roy Bynum [mailto:rabynum@xxxxxxxxxxxxxx]
> Sent: Tuesday, March 14, 2000 11:35 PM
> To: McCormick, Corey
> Cc: 802.3ae
> Subject: Re: Unified PMD vs. Unified PHY
>
>
> Corey,
>
> Actually, the reflector is probably a very good
> place to discuss this. I think that you have an interesting
> question that
> should be addressed. It goes directly to the efficiency of
> improving MAC
> transfer rate by IPG compression.
>
> The average datagram size that I refereed to was
> originally from Internet MCI and then again from vBNS and
> UUNet. These are
> diverse sources, in both time and typical access. Internet MCI was
> functional before the massive numbers of high speed dial up
> ISPs came into
> being. The vBNS network is primarily universities with direct circuit
> access. UUNet is a NSP that supports dial ISPs and
> commercial services with
> direct circuit access. That the average datagram size has not changed
> speaks more to the applications on the desk tops and in the
> homes than to
> the access method. As more and more voice, which uses a very small
> datagram, and video, which uses a large datagram, become even more
> prevalent, the weighting at the extremes of frame sizes will
> increase, but I
> don't think that will change the overall average Ethernet
> frame size at the
> higher bandwidths such as 10 Gigabit.
>
> While the P802.3ae TF has stated that
> it will not
> take on the issue of increasing the MTU size, I have been
> told that almost
> all of the GbE vendors support jumbo frames. One of the
> problems of having
> larger MTU size years ago was that the technology and cost required to
> support any larger frames was a paradigm based probem. It
> goes back to
> issue why the original microprocessors chips only supported a
> limited amount
> of memory, or why the original PC only supported 640K of
> application memory.
> Hindsight is allways 20/20. Those of us that have been
> around long enough
> and worked in enough diverse environments, to understand how
> and why things
> got where they are, have the oportunity to perhaps avoid some
> of the same
> types of mistakes.
>
> Thank you,
> Roy Bynum
>
>
> ----- Original Message -----
> From: McCormick, Corey
> To: Roy Bynum
> Sent: Tuesday, March 14, 2000 10:57 PM
> Subject: RE: Unified PMD vs. Unified PHY
>
>
> I did not know if this was
> correct for the
> reflector, so I thought I would take this offline.
>
> While the average size of ~380 may be
> correct, this new standard is for the future. The current
> ~380 byte size I
> believe is due to the presence of predominately a Wintel architecture
> throughout the Internet community. The current installed
> base of Wintel
> 95/98 dial-up networking uses a default IP MTU of 576 for all
> connections
> less than ISDN 2B (128Kbit/sec). That means to me:
>
> Dial-up connections over the
> next few years
> are being replaced with technologies that push the average
> packet size way
> up:
>
> * Cable-modems, Satellite and
> xDSL - 1500
> MTU
> * E business-business
> transactions - 1500
> MTU
> * VPN tunnels. - default MTU +
> VPN wrappers
>
> * Faster speeds mean more graphics-rich
> traffic as the users continue to crave higher bandwidth
> commodities (Video,
> Audio, Visually Interactive content, etc...) These tend to
> fill up the TCP
> receive window with more full-size packets versus smaller ones.
>
> * Selective acknowledgements
> being added to
> the installed base now mean the 20-40 byte ack packets that drive the
> average down low now will continue to wane.
>
> * Win2K support of RFC-1323 TCP
> options for
> very large TCP receive windows (640Kbytes+) will mean many
> more (400+)
> full-size packets can be "in flight" before the small ack
> packets are seen.
>
> I believe these will all push
> the average
> packet size up quite a bit, while voice over IP will tend to
> want to drive
> it down.
>
> I guess what I am saying is
> that I think 400
> maybe too small to assume. I am not arguing for or against
> the Uniphy just
> sharing some experience...
>
> As a side note, where I hang my work hat
> these days, we are using 9Kbyte Jumbo Frame Ethernet since we
> cannot afford
> the CPU overhead of even single GigE speeds on current
> systems. The TCP
> segmentation/checksum operations are just too great with
> these small (1500)
> MTU packets to utilize the speed of our GigE pipes. As the
> adapters/OS
> interfaces get smarter, some of this will get better I am
> sure, but much
> larger would be better for almost everything except the
> Internet. Vendor
> complain about the compatibility and ASIC troubles, but the
> users have to
> live with things for many years after the ASICs are done and
> the products
> are no longer being sold. Current architectures just do not have the
> capability to do all this well. We are only running normal
> business apps
> SAP, Database, WP, Printing, etc... for these things. (no specialty
> seismic, simulation, etc...) Besides, even Bob Metcalf said
> if he could
> change one thing, it would be to make the MTU larger.
>
>
> Thanks for your time, you all
> have a lot to
> work out, but I am sure you will get there.
>
> Good Luck...
>
> -Corey McCormick
>
> CITGO Petroleum
>
>
>
> -----Original Message-----
> From: Roy Bynum [
> mailto:rabynum@xxxxxxxxxxxxxx]
> Sent: Tuesday, March 14, 2000 8:34 AM
> To: Benjamin J. Brown; 802.3ae
> Subject: Re: Unified PMD
> vs. Unified
> PHY
>
>
> 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
> >
> -----------------------------------------
>
>