| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Ethernet itself is often used in low latency applications and switches. Since the FCS is at the very end of the packet, the entire packet would need to be buffered
before it could be discarded. This introduces latency. For this reason, Ethernet MACs can operate in one of two modes, store-and-forward or cut-through. Store-and-forward does indeed buffer the entire packet and discard it if there is some error (like FCS).
Cut-through mode avoids the latency associated with buffering and will simply forward the packet (corrupt or not). I would image that cut-through mode would be the most common use case for RoE. I think we all agree that retransmission is not practical, however, I’m concerned about the impact of losing an entire packet – probably hundreds of samples
for the due to rare single bit errors. If we could encapsulate the IQ payload with FEC we could avoid this. I’m not suggesting we mandate anything here, however I do believe an option would be valuable. FEC does introduce latency but (depending on type) it
should be small compared to buffering the entire packet and close to negligible compared to the other latencies in the network. Looking into the future and NGFI, we may have different packets types for different channels. In this case, for example, we may wish to FEC control channels
but not the PDSCH. Thanks, Richard From: stds-1904-3-tf@xxxxxxxx [mailto:stds-1904-3-tf@xxxxxxxx]
On Behalf Of Marek Hajduczenia 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]
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]
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]
That goes against any principles of Ethernet links – errored packets are NOT propagated across links.
From: Devi, Sriram [mailto:sriram.devi@xxxxxxxxx]
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 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 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).
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. |