| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
I believe that Ariel was referring to a variable minimum IPG to guarantee that the packet data rate out of the MAC is less than or equal to the payload data rate of the OC-192 SONET frame.
As for your concerns of oversubscribing the bandwidth of the network or the bandwidth between the PHY and the MAC, that is an implementation issue. The standard doesn't prevent people from making stupid implementations, it just ensures that vendor A's implementation works with vendor B's implementation if they both follow the letter of the standard.
Brad
-----Original Message-----
From: Roy Bynum [SMTP:RBYNUM/0004245935@xxxxxxxxxxx]
Sent: Wednesday, August 04, 1999 4:50 PM
To: IEEE HSSG; Ariel Hendel
Subject: Re: Data rate standards vs internal switching standards
Ariel,
In a fixed, constant signal encoding system, the IPG will be variable.
That is not the issue. The individual frames will be mapped into the
constant encoded signal. As for the IPG it is more a matter of what
the minimum IPG is.
Over the years, I have seen many installations that attempted to
aggregate more traffic over a given link than the link could properly
handle, with loss of data. Active flow control addressed this as a far
end resource issue. Active flow control does not however address this
from an internal output resource issue. Variable IPG does not resolve
this issue. Without some sort of transfer rate flow control, from the
PHY to the MAC, to the internal switch functions, data will be lost
at the MAC to PHY interface. The simplest solution is to have the
MAC and the PHY at the same rate. This is the issue that I have.
Perhaps another question to ask is; would the existing active flow
control be limiting at the far end PHY transfer rate, or at the far
end MAC transfer rate. If far end flow control was acting at the far
end PHY transfer rate, it would resolve all of these issues. If it
will only operate at the far end MAC rate, there is still not a good
solution for a variable transfer rate between the MAC and internal
switch functions and the PHY. Even with a far end PHY transfer rate
flow control, there is the issue of distance induce latency in the
control process.
I don't have a good solution to this issue. I have seen several people
recognize that there is an issue. I have not seen an effective solution
that goes beyond the PHY to MAC interface. I am not sure that there
needs to be one. Unless I missed it, I have not seen anyone address
this from an over all architectural process view.
Thank you,
Roy Bynum
MCI WorldCom
Date: Wed Aug 04, 1999 1:17 pm CST
Source-Date: Wed, 04 Aug 1999 12:17:07 -0700 (PDT)
From: Ariel Hendel
EMS: INTERNET / MCI ID: 376-5414
MBX: Ariel.Hendel@xxxxxxxxxxx
TO: Ariel.Hendel
EMS: INTERNET / MCI ID: 376-5414
MBX: Ariel.Hendel@xxxxxxxxxxx
TO: stds-802-3-hssg
EMS: INTERNET / MCI ID: 376-5414
MBX: stds-802-3-hssg@xxxxxxxx
TO: * ROY BYNUM / MCI ID: 424-5935
Subject: Re: Data rate standards vs internal switching standards
Message-Id: 99080419174926/INTERNETGWDN2IG
Source-Msg-Id: <199908041917.MAA10793@xxxxxxxxxxxxxxxxx>
U-X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc
U-Content-MD5: 69p3WqBWFonAMT3e6pMkzA==
Roy,
I was hoping for a YES/NO answer on whether a variable IPG
over a 10Gbps is acceptable to you.
Let me answer your questions and re-submit the question.
Ariel
> Date: Wed, 04 Aug 1999 14:49:45 -0400 (EDT)
> From: Roy Bynum <RBYNUM/0004245935@xxxxxxxxxxx>
> Subject: Re: Data rate standards vs internal switching standards
> To: Ariel Hendel <Ariel.Hendel@xxxxxxxxxxx>, stds-802-3-hssg
<stds-802-3-hssg@xxxxxxxx>
> Content-transfer-encoding: 7BIT
>
> Ariel,
>
> Where would the additional bytes of the variable IPG originate?
The MAC.
> Where would they go?
To the PHY.
(If you want to send them across OC-192 or not that is your prerrogative).
> What would happen to them between the MAC and the PHY?
Nothing. They just go.
> What happens when the MAC at 10.0 gb is operationally overloaded?
There is no transmit resource in 802.3 that can become overloaded.
Queuing is not part of the MAC layer model.
> How do you tell that the PHY is operationally overloaded beyond 9.584
> gb?
Will not happen. The variable IPG is there to limit the rate to 9.584.
> How would you tell the difference? Is there any difference?
>
> Would not putting a limit on effective transfer rate at the MAC by the
> PHY be the same as putting the limit on the MAC to start with? I
> personally can not see any difference, except that you loose
> visibility of the start of overloading conditions at the network
> management level.
>
...
>
> Date: Wed Aug 04, 1999 11:12 am CST
> Source-Date: Wed, 04 Aug 1999 10:11:26 -0700 (PDT)
> From: Ariel Hendel
> EMS: INTERNET / MCI ID: 376-5414
> MBX: Ariel.Hendel@xxxxxxxxxxx
>
> TO: Ariel.Hendel
> EMS: INTERNET / MCI ID: 376-5414
> MBX: Ariel.Hendel@xxxxxxxxxxx
> TO: stds-802-3-hssg
> EMS: INTERNET / MCI ID: 376-5414
> MBX: stds-802-3-hssg@xxxxxxxx
> TO: * ROY BYNUM / MCI ID: 424-5935
> Subject: Re: Data rate standards vs internal switching standards
> Message-Id: 99080417120456/INTERNETGWDN1IG
> Source-Msg-Id: <199908041712.KAA03822@xxxxxxxxxxxxxxxxx>
> U-X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc
> U-Content-MD5: NFmZkLW1UAJg7cpef41TRw==
>
>
> > Date: Wed, 04 Aug 1999 10:19:28 -0400 (EDT)
> > From: Roy Bynum <RBYNUM/0004245935@xxxxxxxxxxx>
> > Subject: Re: Data rate standards vs internal switching standards
> > To: Ariel Hendel <Ariel.Hendel@xxxxxxxxxxx>, stds-802-3-hssg
> <stds-802-3-hssg@xxxxxxxx>
> >
> > Ariel,
> >
> > Actually, I am not in favor of a programmable IPG. I think that the IPG
> > should be set to minimum for all frames in full duplex 10GbE. With 400
> > bytes as the current average size of Internet 802.3 frames, I don't
> > think that there will be enough "slop" to make up the difference
> > between a 10.0 gb MAC and a 9.584 gb PHY. In the future, with more
> > and more video based applications, the average size of the data frame
> > will be increasing. This will only cause the MAC buffer discard rate
> > to increase if the MAC and PHY are not data rate matched. I would much
> > rather see the data rate be defined at the MAC, not the PHY.
> >
>
> My apologies for being dense on this thread, just one last hypothetical
> question for Roy.
>
> Would you accept a 10Gbps rate along with a variable IPG?
> The IPG is just simple function of the length of the last packet sent
> to guarantee that the payload rate does not exceed your OC-192 rate.
>
> Open loop, interoperable, no pins, no thresholds, no nothing.
>
> Would you settle for that or you still prefer the 9.xyz rate?
>
>
>
> Thanks,
>
>
> Ariel
>