Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
   Glossary   Glossary
 
Please login or register.

Login with username, password and session length
Advanced search  

News:

Pages: [1] 2

Author Topic: ADSL/ATM Error recovery and retransmission  (Read 5512 times)

aesmith

  • Kitizen
  • ****
  • Posts: 1216
ADSL/ATM Error recovery and retransmission
« on: November 13, 2015, 11:37:55 AM »

Hi,

I'm familiar with enterprise networks, but have no first hand knowledge of ADSL.  I was in conversation recently with a tech at our ISP regarding a performance issue, and it came to light that neither of us was sure about what level of retransmission exists over the DSLAM to modem path.  The ISP guy was pretty sure there is some sort of retry at the ATM level, although he was not sure of any details.  On my side I was simply assuming there would be none, on the basis that in the sort of networks I'm familiar with there's no retransmission  at Layer 2 even if only because you don't know what the requirements of the upper layers are (for example retrying an IP voice packet is worse than dropping it).   On the other hand ATM and ADSL are quite different from other protocols.

Does anyone have a definitive answer?   The exact context in my case is ADSL 1, the standard "Max" service on 20CN.   We were discussion the issue with particular reference to how much latency could be added by any such retransmission mechanism.

Any information would be appreciated,

Thanks,  Tony S
Logged

roseway

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 43467
  • Penguins CAN fly
    • DSLstats
Re: ADSL/ATM Error recovery and retransmission
« Reply #1 on: November 13, 2015, 11:45:59 AM »

There's a good description of error correction on xDSL here: http://www.kitz.co.uk/adsl/error_correction.htm

On VDSL2 systems (not your question I realise), retransmission is embodied in G.INP - see here: http://www.kitz.co.uk/adsl/ginp-retransmission.htm
Logged
  Eric

aesmith

  • Kitizen
  • ****
  • Posts: 1216
Re: ADSL/ATM Error recovery and retransmission
« Reply #2 on: November 13, 2015, 11:54:24 AM »

Thanks, I was looking at that page but it doesn't really go into detail about where ARQ is actually implemented, or how it works, for example any form of retransmission implies storage of the data ready for possible retransmission and either a windowing mechanism or a simple acknowledgement per packet.   That's the sort of detail I was looking for.   (I've also seen other material suggesting that it isn't implemented in typical DSL modems in any case).   
Logged

ejs

  • Kitizen
  • ****
  • Posts: 2078
Re: ADSL/ATM Error recovery and retransmission
« Reply #3 on: November 13, 2015, 03:36:53 PM »

The higher level requests for retransmission would be TCP. I don't think there is any retransmission without G.INP, otherwise they wouldn't have needed to do G.INP separately (G.INP does exist for ADSL2 and ADSL2+, but not on any BT equipment, although the newest 21CN exchanges appear to get Broadcom equipment so probably would be capable of doing it).

Also, regarding HEC errors, it actually states in the ITU-T technical recommendations that no error correction is performed (G.992.1 7.2.3.6 and G.992.3 K.2.8.5). In general ATM networks, yes the HEC could correct a single bit error, but apparently that ability is not used on ADSL.

AFAIK, if part of your ICMP ping packet gets corrupted and fails the CRC check, there's no "ARQ", and the packet is lost.

Logged

aesmith

  • Kitizen
  • ****
  • Posts: 1216
Re: ADSL/ATM Error recovery and retransmission
« Reply #4 on: November 13, 2015, 09:38:48 PM »

Do you happen to know if there's a published SIN for the IP Stream Max product?  That might be the best official definition.
Logged

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: ADSL/ATM Error recovery and retransmission
« Reply #5 on: November 13, 2015, 11:04:05 PM »

The index to BT's SINs is here. I wonder if SIN 485 is the relevant one?  :-\
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

aesmith

  • Kitizen
  • ****
  • Posts: 1216
Re: ADSL/ATM Error recovery and retransmission
« Reply #6 on: November 14, 2015, 04:46:18 PM »

Thanks, I need to read both that one and 346 which is the original ADSL interface.   At the moment by ISP is firmly stating that errored cells are retransmitted at the ATM layer, and therefore line errors between DSLAM and modem can cause latency rather than loss of data.  I will see what the SINs say.   

Tony S
« Last Edit: November 14, 2015, 04:48:25 PM by aesmith »
Logged

ejs

  • Kitizen
  • ****
  • Posts: 2078
Re: ADSL/ATM Error recovery and retransmission
« Reply #7 on: November 14, 2015, 04:57:50 PM »

I don't suppose the person at the ISP who told you that could tell us which part of the G.992.1 or other ITU document describes that process!
Logged

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: ADSL/ATM Error recovery and retransmission
« Reply #8 on: November 14, 2015, 04:58:12 PM »

It was a number of years ago when I last read SINs 346 & 485, so long ago that I have forgotten the relevant details . . .  :-\
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

ejs

  • Kitizen
  • ****
  • Posts: 2078
Re: ADSL/ATM Error recovery and retransmission
« Reply #9 on: November 14, 2015, 05:51:22 PM »

Quote from: https://technet.microsoft.com/en-us/library/cc976959.aspx
The ATM Layer

The ATM layer provides cell multiplexing, demultiplexing, and VPI/VCI routing functions. The ATM layer also supervises the cell flow to ensure that all connections remain within their negotiated cell throughput limits. If connections operate outside their negotiated parameters, the ATM layer can take corrective action so the misbehaving connections do not affect connections that are obeying their negotiated connection contract. The ATM layer also maintains the cell sequence from any source.

The ATM layer multiplexes and demultiplexes and routes ATM cells, and ensures their sequence from end to end. However, if a cell is dropped by a switch due to congestion or corruption, it is not the ATM layer's responsibility to correct the dropped cell through retransmission or to notify other layers of the dropped cell. Layers above the ATM layer must sense the lost cell and decide whether to correct it or disregard it.

In the case of interactive voice or video, a lost cell is typically disregarded because it would take too long to resend the cell and place it in the proper sequence to reconstruct the audio or video signal. A significant number of dropped cells in time-dependent services, such as voice or video, results in a choppy audio or video playback, but the ATM layer cannot correct the problem unless a higher Quality of Service is specified for the connection.

In the case of data (such as a file transfer), the upper layer application must sense the absence of the cell and retransmit it. A file with missing 48-bytes chunks here and there is a corrupted file that is unacceptable to the receiver. Because operations such as file transfers are not time dependent, the contents of the cell can be recovered by incurring a delay in the transmission of the file corresponding to the recovery of the lost cell.

(Bold and italic added by me)

So now I'll have to continue the Internet scavenger hunt / wild goose chase and look up ATM QoS. I think every modem/router is configured for UBR by default.
Logged

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: ADSL/ATM Error recovery and retransmission
« Reply #10 on: November 14, 2015, 06:01:00 PM »

I think every modem/router is configured for UBR by default.

I, likewise, believe that to be the case.
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

aesmith

  • Kitizen
  • ****
  • Posts: 1216
Re: ADSL/ATM Error recovery and retransmission
« Reply #11 on: November 14, 2015, 06:35:37 PM »

You're ahead of me, I've just worked down from the SINs via a detour to ITU for G.DMT, then back on track I think looking at PPP over AAL5 in rfc2364.  (SIN references rfc1483, which is superseded by 2364).  Got as far as confirming that AAL5 has a single CRC for the upper layer packet, not per cell.   That implies no error detection per cell?  Unless there's an inherent ATM  detection mechanism and the per packet CRC is to detection missing, not errored cells?  I guess you can see I'm not familiar with ATM.

More reading needed. 
Logged

ejs

  • Kitizen
  • ****
  • Posts: 2078
Re: ADSL/ATM Error recovery and retransmission
« Reply #12 on: November 14, 2015, 06:54:33 PM »

I think the bit I quoted and put in italics may be intended to mean that ATM QoS could prevent cells being dropped due to congestion on the ATM network, by configuring a guaranteed to be available bandwidth beforehand. And not that some ATM QoS setting will switch on this mystical "ATM cell retransmission" mechanism.
Logged

aesmith

  • Kitizen
  • ****
  • Posts: 1216
Re: ADSL/ATM Error recovery and retransmission
« Reply #13 on: November 14, 2015, 07:10:07 PM »

Or maybe "mythical".  Of course I've quickly found that ATM does in fact have a cell CRC, called HEC which may be our friend that we see in DSL statistics as HEC errors - does that mean that errors called CRC in the DSL statistics actually refers to the AAL5 CRC?   Still found nothing about retransmission, and since ATM was designed for low latency networking I can't imagine it's a single packet single acknowledgement mechanism, so retransmission implies sequence and acknowledgement counters, of which I've seen no sign yet.
Logged

kitz

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 33879
  • Trinity: Most guys do.
    • http://www.kitz.co.uk
Re: ADSL/ATM Error recovery and retransmission
« Reply #14 on: November 14, 2015, 09:21:47 PM »

Quote
At the moment by ISP is firmly stating that errored cells are retransmitted at the ATM layer, and therefore line errors between DSLAM and modem can cause latency rather than loss of data.

AIUI

CRC is just notification of an error and passed to higher level ie ARQ.
HEC type error is a very simple attempt to reconstruct data, if it cant then it will also pass to a higher level.

I dont think retransmission of CRC/HEC can done at the ATM level and afaik its simply there to record that an error occurred at say the ATM level.   Using DLM the SP can then make use of redundancy to reduce the amount of CRC errors generated.

If a CRC occurs then this causes latency whilst the packet is requested end to end.   Get a lot of CRCs together and the lag is very noticeable even when browsing.


Try looking at Frame check Sequences

Quote
If the values do not match, an FCS error is generated, the frame is discarded and the originating host is notified of the error.


The benefit of G.INP retransmission is that it is done between modem and dslam, therefore greatly reducing latency whilst packets are resent... its something like 2ms rather than say 15,20,35 ms etc.  What is new about G.INP is that a buffer stores packets that can if necessary be resent.
There is more info about how G.INP retransmission works on this page:-
http://www.kitz.co.uk/adsl/retransmission.htm
 

Without G.INP there isnt anywhere else on the path that is capable of storing buffered data to re-request from..  therefore it would have to be end to end point eg PC to web server? 

Also we must not get confused with FEC such as RS which is error protection via redundancy.  It is  reconstruction rather than retransmission.  FEC is done at a lower level ie modem and dslam.   
Logged
Please do not PM me with queries for broadband help as I may not be able to respond.
-----
How to get your router line stats :: ADSL Exchange Checker
Pages: [1] 2