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

Re: Data rate standards vs internal switching standards




I profusely apologize for sending multiple messages on a single day,
I never thought I would get to that, but I feel we are on the verge
of a breakthrough. Please let me try again to get a YES/NO answer
and I will disappear from your screens for a while.

Roy, I am asking if a 10Gbps rate with a variable IPG implemented 
in the MAC to maintain the 9.xyz payload rate is equivalent for you
to the 9.xyz rate you originally requested. If it is, we would have
made significant progress. If it is not, feel free to say NO.

Pictorially, by variable  I mean that the MAC adjusts the actual IPG to make
sure the duration of (a) is no shorter than the duration of (b).


(a)	<      Packet         |  actual IPG  >   	@10 Gbps
(b)	<      Packet             |  min IPG >   	@9.xyz Gbps
	
	

Let's assume everything else is equal and that IEEE will not do
application notes on network architecture and other switch design 
issues.

Thanks,

Ariel





> Date: Wed, 04 Aug 1999 17:49:52 -0400 (EDT)
> From: Roy Bynum <RBYNUM/0004245935@xxxxxxxxxxx>
> Subject: Re: Data rate standards vs internal switching standards
> To: IEEE HSSG <stds-802-3-hssg@xxxxxxxx>, Ariel Hendel <Ariel.Hendel@xxxxxxxxxxx>
> 
> 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
> > 
>