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:

Author Topic: Variable reliability design  (Read 1707 times)

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Variable reliability design
« on: May 22, 2018, 06:59:15 AM »

This suggestion has some associate design difficulties due to the way in which usual isolation in layering of communications architectures (I require a broader term than just ‘protocol stacks’) which frustrates coordinated operation between sometimes distant well-separated layers.

Say you have a ‘non retransmitted’ packet sent by an application, using for example UDP. Another example might be a DNS lookup query or response. Now in contrast TCP data payloads will be resent if lost, the former examples are not.

I wonder would be worth exploring an architecture that used multiple channels by exploiting the availability of multiple DSL latency paths in order to get variable reliability. If I have understood correctly, although this mechanism is intended to provide variable latency by using variable interleave depth, I think you could abuse it to apply variable amounts of FEC and vary other parameters giving far higher reliability on a selective basis.

Examples would be where a DNS-related packet, or something involving UDP that is important, possibly short and only sent as a one-off, not as part of a flow, or even each TCP ACK are all sent in the high-reliability, high-overhead channel.

I don't know what the worth of such a scheme might be. Looked at negatively you could take such a system as a way to push speed harder and harder even to the point where reliability is reduced in situations where retransmissions and eg TCP could fix slightly bellow-par reliability whilst still giving superb reliability for things that really matter and which are exposed.

To achieve this, there would need to either be (1) a kind of side channel where higher layers send down per-packet reliability channel markers, or (2) there would have to be a pattern-matching capability that one or possibly many layers could implement where a higher layer tells lower layers how to recognise SDUs and classify them, or a mixture of the two approaches. The pattern-match thing could be a kludge, prone to miss things, or inflexible or all three. It could also be really awkward to implement as patterns might get variable and messy. It seems to me that the mixed approach (1+2) is the only route to success. Since option 1 has backwards compatibility problems, there is an alternative to 1, using in-band signalling if suitable extra data can be added in an SDU then recognised and removed by the lower layer. There might be cases where this is really problematic, it's something I would need to think about more.

One way of using this would be to have standing orders, where lower layers pattern match and categorise certain types of data, such as "all UDP", or "DNS messages" or "TCP acks" and-lace them into different high reliability channels/categories. This is the kind of thing that is sometimes done for QoS. It avoids the situation where you can make no improvement to the whole system because apps can't all be rewritten to think about such things.

It seems to me that this would definitely not pay off if the cost of retransmissions in say TCP is very high. If a packet gets corrupted and TCP reacts badly then the pushing things harder to compromise some reliability thing would not pay off because the extra raw speed gained would be wiped out by the performance loss when recovering and retransmitting. The only way to answer the question would be to try it.

However, the variable reliability thing might have other worth aside from just trying to get more speed.
Logged

niemand

  • Kitizen
  • ****
  • Posts: 1836
Re: Variable reliability design
« Reply #1 on: May 22, 2018, 06:51:37 PM »

I'm not convinced it would improve performance. By delaying acknowledgements through classifying them and pushing them through a higher latency path you're increasing the BDP of the circuit and degrading maximum TCP performance.

Having asymmetric paths of different latency out of the box can be problematic in some cases.

It also seems a big attempt to solve a problem that isn't really too troublesome by adding lots of extra complexity and overhead.
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Variable reliability design
« Reply #2 on: May 22, 2018, 11:09:50 PM »

No, the point is that you would be using the ‘latency’ path mechanism in a different way, so that it doesn't add latency at all, only increases the level of FEC, ie more R not using interleave at all. So no extra delay. And no throughput reduction because it is only used on one-offs.

I'm not convinced about its value, but I do think it would be worth exploring for very high reliability where you do not want the cost of that extreme level of reliability everywhere, so much that throughput is reduced substantially on routine bulk data transfer that doesn’t absolutely need quite that level of protection.
Logged

kitz

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 33881
  • Trinity: Most guys do.
    • http://www.kitz.co.uk
Re: Variable reliability design
« Reply #3 on: May 23, 2018, 10:34:39 PM »

Something like this?
Multipath FEC Scheme for the ATM Adaptation Layer AAL5

>> more R not using interleave at all. So no extra delay.

More R increases overhead and reduces available bandwidth.  FEC processing still adds a small amount of delay for coding and decoding.

G.INP is a more efficient solution in that it doesn't care what type of data it is at the higher level and will re-request only when needed.   So in effect its kind of like putting an ACK around the data packet regardless if its TCP or UDP but very little overheads
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

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Variable reliability design
« Reply #4 on: May 23, 2018, 11:10:31 PM »

Thank you for digging that up. What a great find! Someone else has been thinking about these things. I was pleased to see that in one place I got some basic maths correct too, concerning error rates, I was getting worried.

Kitz is right, G.INP is a better solution. I wonder what happens when you combine the two. Having two low a level of FEC means that the data rate is unpredictable though, it could be that you end up retransmitting parts of this here and parts of that there all over the place and need to put some of the FEC back. I wonder how to get the balance right.

My thing though is that for one-offs, like DNS say, there is almost no cost increase because it is not a bulk activity and it is end-to-end * 2 turnaround time which is all the app cares about. And it was these one-offs that was one use case for my thing. The other thing though, UDP flows should be dealt with by L2 rtx like G.INP, and that is exactly what wireless LANs do for reasons well known. They use a mix of both approaches. On the TP-Link 5GHz WAPs I have, it is amazing how much configurability there is along many axes and you can configure all these different approaches to error control, including size of DTUs for example (data (re-)transmission units, sub-parts of a frame/upper L2 SDU). (In fact for wireless there seems to me a desperate need for a dynamic intelligent adaptive tuning control layer which monitors what is going on in the network, with levels of errors of different types, collisions, level of load, looking out for hidden stations and so on, and tweaks the various numbers so that admins do not have to and can't keep up to date with rapidly changing situations anyway.)
Logged

niemand

  • Kitizen
  • ****
  • Posts: 1836
Re: Variable reliability design
« Reply #5 on: May 26, 2018, 12:03:30 AM »

Here's a way to do it via overlays on existing transport.

[youtube]https://youtu.be/ccgad3lkTv4
[/youtube]

Logged
 

anything