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

RE: Inter-frame transmission length

Bob, Pat,

Thanks for the clarifications.
In my questions I was of course referring to the average MINIMUM IPG length.
I understand that implementing the D1.1 IPG table (Table 46-4) correctly,
fulfills the requirements of 2)  in D3.0 (please correct me if I'm
I did the calculations, and both methods seem to do the same in full
bandwidth case.

I wander if implementing section method 1), which causes loss of
bandwidth, will be accepted by the manufacturers and customers. Using it can
cause congestion (and loss) of packets if a system receives full bandwidth
packets with average IPG using method 2), and transmits them using method
Wouldn't it be wiser to remove method 1)?


> -----Original Message-----
> From:	Grow, Bob [SMTP:bob.grow@xxxxxxxxx]
> Sent:	&bet; &alef;&pe;&resh;&yod;&lamed; 30 2001 20:53
> To:	'Lior Reem'; '802.3ae'
> Subject:	RE: Inter-frame transmission length
> The IPG was and still is created by the MAC as specified in clause 4.  In
> clause 4 a minimum length is specified.  The average IPG cannot be
> specified
> because it is dependent on network load, and that is also true of the RS
> specification in clause 46.
> The start control character alignment function of the RS (see
> either adds or deletes IPG.  The specification through a Deficit Idle
> Count
> (DIC) is such that if a running total of MAC IPG were maintained, the
> aligned data at the XGMII would produce a total IPG that is +0, -3
> compared
> to the MAC IPG total.  Only at maximum frame rate can this be restated as
> maintaining a 12 byte average IPG. 
> In an integrated MAC/RS design, the implementer may choose to either
> always
> add idle to produce alignment, or may produce a design that mimics the
> behavior of the clause 4 bit serial MAC and 32-bit wide RS alignment
> function.  
> The answers to your direct questions:
> The table was removed because of comments from 802.3ae participants.  The
> table was felt by some to be too restrictive and by others as difficult to
> read and even misleading.  The clause still specifies the handling of the
> interframe, but the clause organization was changed significantly since
> D1.1.
> Yes, one of the important characteristics of accepted comments on the
> start
> alignment function is to allow implementer flexability.  This also
> includes
> a modification in TF ballot (i.e., a DIC does not have to be implemented,
> the implementation only has to behave as if it was implemented).
> Another algorithm can be used as long as it behaves like either 1) or 2)
> of
> Conformance is not easily and precisely specified using the average of
> IPG,
> even when only discussing the average at maximum frame rate.  The
> algorithm
> specifies the allowd difference on the total IPG.  An implementation that
> transmitted three back to back frames with the sum of the frame1 to frame2
> IPG and frame2 to frame3 IPG being 21 bytes or more (average >= 10.5) at
> the
> XGMII would is in conformance.  With minimum frame spacing, after a
> million
> frames, the transmitted IPG at the XGMII could be an average of 11.999997
> in
> a conformant implementation, if at the end of the test, DIC = 3.
> --Bob Grow
> -----Original Message-----
> From: Lior Reem [mailto:LReem@xxxxxxxxx]
> Sent: Sunday, April 29, 2001 3:12 AM
> To: '802.3ae'
> Subject: Inter-frame transmission length
> Hi,
> In D1.1 clause, a Table (46-4) was attached, which described how
> to
> implement an IPG of 12 bytes in average.
> Since then, the following draft excluded this table, and almost nothing is
> said about how IPG should be transmitted.
> This clause doesn't even talks about the average IPG length anymore, which
> looks like a real "hole" in the text.
> Why is the inter-frame length table excluded?
> Is it to enable more flexibility? 
> Is it aloud to transmit other IPG length algorithms (any exist)?
> Is it aloud to transmit shorter average IPG?
> Thanks,
> Lior.
> ~~~~~~~~~~~~~~~~~~~
> Lior Re'em
> Avaya Inc.
> Email : lreem@xxxxxxxxx
> ~~~~~~~~~~~~~~~~~~~