Kitz Forum
Broadband Related => Broadband Technology => Topic started by: aesmith 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
-
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
-
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).
-
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.
-
Do you happen to know if there's a published SIN for the IP Stream Max product? That might be the best official definition.
-
The index to BT's SINs is here (http://www.btplc.com/sinet/SINs/index.htm). I wonder if SIN 485 (http://www.btplc.com/sinet/SINs/pdf/485v1p3.pdf) is the relevant one? :-\
-
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
-
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!
-
It was a number of years ago when I last read SINs 346 & 485, so long ago that I have forgotten the relevant details . . . :-\
-
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.
-
I think every modem/router is configured for UBR by default.
I, likewise, believe that to be the case.
-
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.
-
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.
-
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.
-
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 (http://www.juniper.net/techpubs/en_US/junos12.1/topics/concept/interface-security-physical-property-frame-check-sequence-understanding.html)
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.
-
Sorry, just noticed that ejs has said basically similar to me
I don't think there is any retransmission without G.INP, otherwise they wouldn't have needed to do G.INP separately
The quote ejs found from technet, and specifically the part he embolded, confirms what I said in my post above.
-
While you are considering the ATM angle, I can point you separately in the direction of what mechanisms exist in DSL systems in general, courtesy of the Broadband Forum...
Google for TR-197, "DQS: DSL Quality Management Techniques and Nomenclature".
Note that this document covers the full spectrum of techniques, but not all are employed by BT. And techniques have evolved separately in 20CN, 21CN and FTTC.
You would think that, if ATM could offer any quality facilities (such as a retry mechanism) to DSL, it would be mentioned in that document. Even if only as part of the " External" section.
Instead, the only mention of ATM comes within the DSL retransmission section (which is the G.INP mechanism mentioned earlier), saying that retransmission DTU units must be sized to hold an integer number of ATM cells.
Having read that made me think ... We do remember that, while ADSL is designed to accommodate ATM cells, it isn't actually ATM, dont we? Even if ATM included a retry mechanism (I don't think it does either - it is a low latency, guaranteed latency, design), it wouldn't apply because the link between the DSLAM and ADSL modem is not ATM.
That link is governed by the ITU ADSL specifications, which don't have retries. If it did, G.INP would have to accommodate it, and it would be mentioned in TR-197.
-
Thanks for all the comments. What I'm finding is that proving a negative is difficult, there's no trace of an ATM retransmission mechanism mentioned in any of the ITU documents, rfcs or SINs that I've looked at, other then G.INP (ITU G.998.4). I'm finding lots of stuff that I'm not certain about, for example Wombat has just said that DSL is not ATM - but does it not carry ATM? That's got me wondering, I always assumed that the modem recreated the ATM PVC from the DSL, then rebuilt PPP and in turn the Layer 3 packet from the ATM. However I'm not sure where I got that from, maybe just made the assumption because Cisco calls the DSL interface ATM (and the terminology itself of course, PPP over ATM).
I find it perfectly logical to deduce that if ATM already had a retry mechanism, then either G.INP would not be required, or the definition would explain how it differs and offers an improvement over the existing ATM mechanism.
-
I did eventually track down an ATM cell retransmission mechanism, but I don't think it's used with ADSL, if it were then it would surely be mentioned somewhere in some ADSL related document.
I'll send it in a PM to aesmith rather than post it publicly, just in case someone at Plusnet reads this and then points to the document as proof it exists.
-
Got your PM thanks.
-
Thanks for all the comments. What I'm finding is that proving a negative is difficult, there's no trace of an ATM retransmission mechanism mentioned in any of the ITU documents, rfcs or SINs that I've looked at, other then G.INP (ITU G.998.4).
There's probably a reason why!
I'm finding lots of stuff that I'm not certain about, for example Wombat has just said that DSL is not ATM - but does it not carry ATM?
I think the best way to think of this is to separate ATM into two - one being the networks, protocols, routing, rules, specs; the other being the packets of data: cells of 53 bytes, made of 5 bytes of header and 48 bytes of payload.
At one time, BT's core network will have been based on ATM. The whole enchilada, including networks, protocols, routing, rules ... all to carry those 53 byte cells.
http://www2.bt.com/static/i/media/pdf/atm_vpn_dec05.pdf
(In the days of poor QoS in the IP world, ATM was the telecomms solution for a converged network - small cells allowed low latency voice to coexist with high volume data; "ATM" as an overall concept is all about the routing & transmission of these small cells to keep voice working well).
But right on the access edge, the network hits the copper lines and ADSL. Here, the protocols and rules are all pure ADSL, not ATM. At this point, there is little need for the "big" network concepts, and every need for techniques to cope with long, dodgy copper lines. However, the data being carried, right down at the bottom level, remained in the form of little 53 byte packets, aka ATM cells.
The 5 bytes of header become a terrible overhead in there, given that most lines carry a single virtual circuit.
http://aa.net.uk/kb-broadband-how-atm.html
So we get to see that ADSL is carrying ATM cells, but it isn't actually performing any real function that we'd think of as a core ATM network function.
That's got me wondering, I always assumed that the modem recreated the ATM PVC from the DSL, then rebuilt PPP and in turn the Layer 3 packet from the ATM. However I'm not sure where I got that from, maybe just made the assumption because Cisco calls the DSL interface ATM (and the terminology itself of course, PPP over ATM).
Yup, it is indeed that way - at least when ATM mode is used in ADSL. There are also modes for SDH and PTM (which is more used in NGA). More information in the area here...
http://blog.farnz.org.uk/2010/02/on-pppoa-pppoe-atm-and-adsl.html
-
Thanks. I've sort of let ATM pass me by since the early days when it was supposed to be "the way forward". You probably know the time period I mean, when Fore was going to be the next Cisco, IBM backing ATM to the desk rather than Fast Ethernet, etc etc.