RE: Inter-frame transmission length
Lior,
We have never required that a MAC be able to transmit continuous
back-to-back packets. I don't think there is any need to start requiring it.
Method 1 merely acknowledges that some MACs will be built with 4 wide (or
wider) data paths so that they always give the RS aligned start delimiters.
Even if we removed method 1, we can't force the MAC to give the RS an
unaligned start delimiter so that we can test which method the RS is using.
Therefore we should leave it as it is.
Performance testers will continue to test devices such as switches and there
are much larger opportunities to be inefficient than the MAC/RS interface
provides.
Regards,
Pat
-----Original Message-----
From: Lior Reem [mailto:LReem@xxxxxxxxx]
Sent: Tuesday, May 01, 2001 9:29 AM
To: 'Grow, Bob'; 'pat_thaler@xxxxxxxxxxx'; '802.3ae'
Subject: 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
> ~~~~~~~~~~~~~~~~~~~
>