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
> -----------------------------------------