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 46.3.1.4 2) in D3.0 (please correct me if I'm
wrong!).
I did the calculations, and both methods seem to do the same in full
bandwidth case.
I wander if implementing section 46.3.1.4 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
1).
Wouldn't it be wiser to remove method 1)?
Lior.
> -----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 46.3.1.4)
> 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
> 46.3.1.4.
>
> 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 46.2.5.1, 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
> ~~~~~~~~~~~~~~~~~~~
>