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

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