I do not see any compatibility issue here. If a given MAC does not support cut-through mode then the packet will drop. Whilst in this case, FEC has not served
any useful purpose; I don’t believe it has created any incompatibility. Can you explain how intermediate devices need to be RoE aware?
From: stds-1904-3-tf@xxxxxxxx [mailto:stds-1904-3-tf@xxxxxxxx]
On Behalf Of Marek Hajduczenia
Sent: Friday, June 26, 2015 10:49 AM
To: 'Glen Kramer'; 'Akhter, Mohammad'; STDS-1904-3-TF@xxxxxxxxxxxxxxxxx
Subject: RE: Action Points: errors..
… which means it could not run over legacy hardware that is not “RoE-aware” …
From:
stds-1904-3-tf@xxxxxxxx [mailto:stds-1904-3-tf@xxxxxxxx]
On Behalf Of Glen Kramer
Sent: Friday, June 26, 2015 1:45 PM
To: Akhter, Mohammad; STDS-1904-3-TF@xxxxxxxxxxxxxxxxx
Subject: RE: Action Points: errors..
Likewise, the impact of accepting a frame that has an FCS error should be analyzed. This can be detrimental if, for example, a corrupted Control Frame is accepted
and cause the link to be torn down.
The general 802.3 requirement is that all frames with FCS errors should be dropped (i.e., not passed to LLC or MAC Control sublayers). But 802.3 does leave
the door open for forwarding errored frame to “private” layers above the MAC. If this is what 1904.3 decides to do, it will have to define the operation of this private sublayer. The implication of this is that all RoE traffic will require all intermediate
devices to be “RoE-aware”.
Glen
From: Akhter, Mohammad [mailto:Mohammad.Akhter@xxxxxxx]
Sent: Friday, June 26, 2015 10:17 AM
To: STDS-1904-3-TF@xxxxxxxxxxxxxxxxx
Subject: Re: [1904.3 TF] Action Points: errors..
It would be important to understand the impact of error occurrence and dropping for both control and data plane traffic. Control plane error and dropping would potentially lead to loosing frames. At a link level (Mobile to Basestation)
this may lead to retry and degradation in QoS.
Regards,
Mohammad
On Jun 26, 2015, at 11:57 AM, Marek Hajduczenia <marek.hajduczenia@xxxxxxxxx> wrote:
Correct, such an errored packet would be dropped by the first link peer on which FCS check fails and it would not be propagated to the following links.
From: Devi, Sriram [mailto:sriram.devi@xxxxxxxxx]
Sent: Friday, June 26, 2015 11:22 AM
To: Richard Tse; Marek Hajduczenia; 'Steinar Bjørnstad'
Cc: Bross, Kevin; 'Jouni Korhonen'; STDS-1904-3-TF@xxxxxxxxxxxxxxxxx
Subject: RE: Action Points: errors..
Ok understood, in that case packets have to be dropped and the impact on radio link studied.
Sriram
From: Richard Tse [mailto:Richard.Tse@xxxxxxxx]
Sent: Friday, June 26, 2015 8:02 AM
To: Marek Hajduczenia; Devi, Sriram; 'Steinar Bjørnstad'
Cc: Bross, Kevin; 'Jouni Korhonen'; STDS-1904-3-TF@xxxxxxxxxxxxxxxxx
Subject: RE: Action Points: errors..
Regarding “the upper layers should still be presented with all received packets with error indication so that it knows the source of error”: with an FCS error, the Ethernet layer could not figure out which upper layer client should be given the erroneous packet because it doesn’t know which bits in the Ethernet frame are corrupted.
Rich
From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx]
Sent: Friday, June 26, 2015 7:39 AM
To: 'Devi, Sriram'; 'Steinar Bjørnstad'; Richard Tse
Cc: 'Bross, Kevin'; 'Jouni Korhonen'; STDS-1904-3-TF@xxxxxxxxxxxxxxxxx
Subject: RE: Action Points: errors..
That goes against any principles of Ethernet links – errored packets are NOT propagated across links.
From: Devi, Sriram [mailto:sriram.devi@xxxxxxxxx]
Sent: Friday, June 26, 2015 10:36 AM
To: Steinar Bjørnstad; Marek Hajduczenia; Richard Tse
Cc: Bross, Kevin; Jouni Korhonen; STDS-1904-3-TF@xxxxxxxxxxxxxxxxx
Subject: RE: Action Points: errors..
Even though ROE is latency critical and may not have enough time for error recovery, the upper layers should still be presented with all received packets with error indication so that
it knows the source of error (over the air error vs ethernet transport). There are forward error correction schemes to handle OTA errors in 3G/4G.
Sriram
From: stds-1904-3-tf@xxxxxxxx [mailto:stds-1904-3-tf@xxxxxxxx] On Behalf Of Steinar Bjørnstad
Sent: Friday, June 26, 2015 3:38 AM
To: Marek Hajduczenia; Richard Tse
Cc: Bross, Kevin; Jouni Korhonen; STDS-1904-3-TF@xxxxxxxxxxxxxxxxx
Subject: SV: Action Points: errors..
Hello,
While FEC also can be added at the packet layer (this is actually standardized for uncompressed SDI video over IP transfer) as well as at the transmission (bit) layer, we should keep in mind that FEC always adds extra latency (especially at the packet layer because of buffering of several packets.). Since the ROE applications is seen as a latency critical application I think there might not be available time for correction of packets, hence discarding the packet is probably the best option when detecting an error.
Best regards
Steinar
Fra: stds-1904-3-tf@xxxxxxxx [mailto:stds-1904-3-tf@xxxxxxxx] På vegne av Marek Hajduczenia
Sendt: 26. juni 2015 02:42
Til: Richard Tse
Kopi: Bross, Kevin; Jouni Korhonen; STDS-1904-3-TF@xxxxxxxxxxxxxxxxx
Emne: Re: Action Points: errors..
Standard Ethernet FCS does not allow us to identify anything BUT the fact that there are up to certain number of bit errors. FEC adds bit error recovery capabilities, but these happen on hop by hop basis. Adding an E2E FEC would be very complex and certainly NOT backward compatible
Marek
On 25 June 2015 at 19:43, Richard Tse <Richard.Tse@xxxxxxxx> wrote:
If the Ethernet frame has a basic FCS error, we do not know which bit(s) in the frame are corrupt. Thus, we cannot even know for sure which flow the frame belongs to. Making any assumptions and trying to somehow compensate for such an error may make things worse (e.g. corrupting another flow instead of doing something to the one we thought was corrupted).
Rich
-----Original Message-----
From: stds-1904-3-tf@xxxxxxxx [mailto:stds-1904-3-tf@xxxxxxxx] On Behalf Of Bross, Kevin
Sent: Thursday, June 25, 2015 4:28 PM
To: Jouni Korhonen; STDS-1904-3-TF@xxxxxxxxxxxxxxxxx
Subject: RE: Action Points: errors..
Another option would be to pass along the error through TBD (header?) information and let the upper-level layers decide how they want to handle this. Some errors (such as PHY over-temp) may require some higher-level activity (flow throttling, fan speed increase) or the issuance of a maintenance ticket, but may not necessarily impact data reliability. Similarly, an encoding error for dummy data may not impact critical data. At this layer, we simply don't know and don't need to know.
These errors should be infrequent and may or may not impact critical data. I suggest that we indicate the errors within the protocol and leave it for the upper-level errors to figure out what to do with the packet that has this error.
--kb
-----Original Message-----
From: stds-1904-3-tf@xxxxxxxx [mailto:stds-1904-3-tf@xxxxxxxx] On Behalf Of Jouni Korhonen
Sent: Thursday, June 25, 2015 4:03 PM
To: STDS-1904-3-TF@xxxxxxxxxxxxxxxxx
Subject: Action Points: errors..
Folks,
Another AP I got relates to kicking off the discussion on errors originating from PHY/SFP.
We should have an agreement how to deal with those. My take is that we do nothing specific except discard the packet _if_ we manage to detect the error. I don't really see how we could do otherwise. We don't have enough information to do more clever recovery/heuristics.
- Jouni
--
Jouni Korhonen, CTO Office, Networking, Broadcom Corporation
O: +1-408-922-8135, M: +1-408-391-7160
Confidentiality Notice.
This message may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any use, disclosure, dissemination, distribution, or copying of this message, or any attachments, is strictly prohibited. If you have received this message in error, please advise the sender by reply e-mail, and delete the message and any attachments. Thank you.