Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Weaver]

Could anyone point me to any info about the use of ARQ inside DSL modems? (If it is used at all in the ADSL flavours found in the UK.)

[orainsear]

Could be way off the mark but isn't Cyclic Redundancy Checking (CRC) and error correction a kind of ARQ?

Edited to add error correction

[Azzaka]

ARQ (Automatic Repeat Request) is a form of Error correction. From what i can find ARQ is used primarily in Video Encoding and not just normal encoding. I would also make the suggestion it can be found on routers liek Cisco and Juniper, but I would have dig further for others such as Netgear and Draytek.

Also whether this would be done via the DSL chip or via the DSLAM/MSAN is something that would need to be checked as well.

[Weaver]

So do we think that if FEC in your DSL modems fails, including all the various types of error correction permitted by redundancy, then your average DSL modem won't request a retransmission? So this would mean for example that PPP could break, and protocols above IP will be either fine (TCP) if they incorporate their own retransmissions, or broken (eg naked UDP)?

Basically this would mean that DSL modems are very unlike modern dial-up modems with full at-all-costs error correction?

ARQ inside a DSL modem would seem to me to be a good idea as the DSL modem is the only system that knows that a packet has been received but received corrupted as opposed to simply lost/dropped because of congestion or breakage, and so is the only system that can get speedy retransmissions underway, sparing the rest of the network from end-to-end retransmissions. But if you don't want reliable service, or you are operating a time-critical protocol where dropping packets is better than getting behind, or forty other reasons, then I don't see how you could talk to the DSL modem and turn such a mechanism off, and you'd need to do so selectively. The only way I could see such a thing working would be to have various flags in higher level protocols' headers that 'document' the type of service needed, not in terms of priority/'urgency'/real-timeness/traffic classes/flows as has been done in the past, but in terms of '(un)reliability-requested' and have a DSL router's protocol stack 'snoop' on higher protocols, a method that would be rather hit-and-miss. Ugh.

[Azzaka]

So do we think that if FEC in your DSL modems fails, including all the various types of error correction permitted by redundancy, then your average DSL modem won't request a retransmission? So this would mean for example that PPP could break, and protocols above IP will be either fine (TCP) if they incorporate their own retransmissions, or broken (eg naked UDP)?

Basically this would mean that DSL modems are very unlike modern dial-up modems with full at-all-costs error correction?

ARQ inside a DSL modem would seem to me to be a good idea as the DSL modem is the only system that knows that a packet has been received but received corrupted as opposed to simply lost/dropped because of congestion or breakage, and so is the only system that can get speedy retransmissions underway, sparing the rest of the network from end-to-end retransmissions. But if you don't want reliable service, or you are operating a time-critical protocol where dropping packets is better than getting behind, or forty other reasons, then I don't see how you could talk to the DSL modem and turn such a mechanism off, and you'd need to do so selectively. The only way I could see such a thing working would be to have various flags in higher level protocols' headers that 'document' the type of service needed, not in terms of priority/'urgency'/real-timeness/traffic classes/flows as has been done in the past, but in terms of '(un)reliability-requested' and have a DSL router's protocol stack 'snoop' on higher protocols, a method that would be rather hit-and-miss. Ugh.

You may want to look at ]Extended Ethernet Frames. Essentially resubmits the packets and can rebuild at the other end.

[kitz]

Sorry only just seen this. - Yes adsl utilises ARQ

Theres a little bit on the main site about ARQ : http://www.kitz.co.uk/adsl/error_correction.htm#ARQ

and also mentioned in the CRC section: http://www.kitz.co.uk/adsl/error_correction.htm#CRC

CRC is error detection only.  The modem's decoder signals a loss of data (erasure)
Once an error has been detected its ARQ  thats responsible for actually re-requesting the data.
ARQ is a protocol.. and higher up in the 7 layer OSI model


I'd have to check to be certain but I think these are the levels at which each is performed:-

• ARQ is transport layer
• CRC is done at the datalink layer
• and FEC at the physical layer (not to be confused with FEC done at the application layer by some types of media software for streaming etc)

.[some pretty pics I prepared many years ago & already up elsewhere for another topic]




 


>> So do we think that if FEC in your DSL modems fails,

FEC is completely separate to CRC and ARQ.
FEC is data that has been (RS) encoded with some redundancy so that data can be reassembled.   If too much of the data is lost for recovery...  then a CRC is signalled.

CRC is an error.. whilst FECs are recovered data from the redundancy.

You raise an interesting point about 'if FEC fails'...  because something that is little known... is that interleaved data is passed via a different channel non-interleaved traffic.
I'd have to get my text books out to refresh memory though Im afraid.  
Perhaps if 7LM is reading he could comment since I believe the OSI is 'his area'?  

[sevenlayermuddle]

Perhaps if 7LM is reading he could comment since I believe the OSI is 'his area'?  

Oooh err, is this where I'm exposed as a fake?    Somebody once said 'better to remain quiet and appear foolish, than to speak out and remove all doubt'.

I must admit I'd been tempted to chip in to this thread, but there's a few flaws and gaps in my knowledge.  In my defense, I'd just stress that TCP/IP isn't OSI and so doesn't always follow the 7 layer model.  Please be gentle with me if I've got anything wrong...  

Basically, I agree with kitz.  The modem(/router) is layer 1 (PHY).  The data link layer, which needs to be closely coupled with PHY, is usually responsible for error detection (using CRC).  In principle (but see note * below) it's not really accurate to say that the modem 'knows that a packet has been received but corrupted'.  All the modem's data link knows (based on a bad CRC) is that some data had been received which was so badly corrupted that it must be regarded as garbage.  Being garbage, no assumptions can be made about what the data was intended to contain. Since the modem doesn't know, at that level, what data was corrupted, it can't ask for it to be resent.

ARQ comes in higher up the stack, and is facilitated by inserting sequence numbers in the protocol headers, and requiring the receiver to acknowledge receipt.   The sender runs a timer and if a given sequence number isn't acknowledged in good time, it gets resent.   Additionally, if a packet has been lost, the receiver  will see a 'gap'  in the sequence numbers, and a request can be made for retransmission of the missing packet number.  ARQ can be used either to recover data that has been lost due to corruption (CRC errors), or for data that was discarded owing to flow control or congestion somewhere between the sender and receiver.  

Various protocol layers provide some degree of ARQ.  Layer 2 sometimes does provide error recovery as well as detection, where recovery from data corruption errors is a priority.  The layer 2 ( connectionless LLC) used in a typical ethernet IP stack does not.  AFAIK,  ARQ in such an IP stack is left to TCP (which is layer 4-ish, as per Kitz's diagram).

There are also some situations where data is retransmitted pre-emptively.   For telecomms earth-to-satellite links, the propagation delay for data acknowledgement can be quite long (several hundred ms) so, when the link is idle, rather tnan send nothing at all, the sender may continuously retransmit data it's already sent just in case it's needed.

ARQ does has some trade-offs.  The sender needs to keep a copy of the data until the receiver has acknowledged it, and that can require a larger memory footprint.  The acknowledgement timers can consume CPU resource, or need a faster CPU.   Additonally, the sender has a finite 'window' of sequence numbers that it can send before acknowledgent is needed.  When the window is full, the sender stops sending until some acknowledgements are received, which can lead to periods of inactivity while the acknowledgement timer expires.  The sequence numbers, and acknowledgement packets, also consume extra bits in the data stream, and so have an adverse effect on usable data rates.

In the case of DSL routers, I believe (not entirely sure of this) G.992 sets a target BER (Bit Error rate) of 1 in 10^7 at an SNRM of 0dB (that's sort of the definition of 'SNRM').  It's possible that the designers have deemed that, by meeting that error rate, error recovery at L2 isn't justified, which would be OK as the occasional error will be picked up by TCP's ARQ.   As for the ATM side of things I don't really know enough to pass comment I'm afraid, though there may be relevant factors.

* Note: One thing I'm not sure about is whether DSL superframes contain any kind of sequence numbers.  If they do, then as soon as the next superframe is received the router would see a gap in the sequence numbers and so would in fact know which superframe has been corrupted?

edited (twice, I wish I'm beginning to wish I'd never started this) for typos and clarifications

[kitz]

Thanks very much for that contribution 7LM -  mucho appreciated.

>> I must admit I'd been tempted to chip in to this thread, but there's a few flaws and gaps in my knowledge.

Please dont knock yourself..  Im sure you still know way more about the subject than most of us...  its several years since I covered the subject in any depth so my knowledge is rusty hence me calling on you