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
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
|