[AusNOG] ADSL2+ line sync data

Sat Sep 14 10:15:24 EST 2013

>________________________________
> From: Joshua D'Alton <joshua at railgun.com.au>
>To: 
>Cc: "ausnog at lists.ausnog.net" <ausnog at lists.ausnog.net> 
>Sent: Friday, 13 September 2013 10:25 PM
>Subject: Re: [AusNOG] ADSL2+ line sync data
> 
>
>
>That RFC isn't very accurate/applicable any more, the bandwidths we're talking about now throws most of those calculations and factors etc out of the window. The maths is still solid, but the results are ... not. Stream delay (buffer size, mean RTT for a single TCP packet etc) now being 100th of what it was with dialup, and so on.
>

It's still an IETF Best Current Practice. The IETF will deprecate BCPs if they don't apply any more. Given that that are over 6000 RFCs, and only 183 BCPs, RFCs are not given BCP status without significant consideration.

If you think it only applies to dialup, then I don't think you've read it.

For example, from the appendix,

     "Most data over cable TV networks (e.g., DOCSIS [ITU01, DS00]),
      where the analogue channels assigned for upstream communication
      (i.e., in the reverse direction) are narrower and may be more
      noisy than those assigned for the downstream link.  As a
      consequence, the upstream and downstream links differ in their
      transmission rate. For example, in DOCSIS 1.0 [DS00], the
      downstream transmission rate is either 27 or 52 Mbps.  Upstream
      transmission rates may be dynamically selected to be one of a
      series of rates which range between 166 kbps to 9 Mbps."

A broadband speed of DOCSIS best case 52Mbps/9Mbps is certainly not dialup.

>
>Google might have that Q and A, and they are correct in theory that it will let you upload alot as well (whatever that means *caugh P2P caugh*), but they needn't have gone anywhere near symmetrical to rule out 99.999% risk of downloads being slowed due to upload congestion. Put another way, looking at that 18/1 vs 11/11 the majority of users will be experiencing downstream congestion before they see upstream congestion.
>

It's the ratio of downstream to update bandwidth that matters, and the likelihood of congestion in the upstream direction, not so much the bandwidth involved. The greater the ratio of downstream to upstream bandwidth, the more likely the problem is going to occur.

A single TCP stream is less likely to see this issue, as there is very little competition for uplink bandwidth that can cause ACKs to be queued and therefore delayed. However, have a large upload going (e.g. video upload to youtube) while also having a large download going (e.g., watching a youtube video), and you're more likely to see the download effected because of ACK queuing and therefore delaying occurring on the uplink.

Symmetry doesn't eliminate congestion (nothing does), but it can provide equal performance and quality in both directions for TCP and other protocols and applications. Video can be the same quality in both directions, not better in one direction than the other (asymmetry of bandwidth is going to put a real cramp on telemedicine, as the patient will see the doctor really well, but the doctor won't see the patient really well - and doctors won't accept that because their malpractice premiums would then go up). Uploads will have as much congestion effect as downloads. 

>
>I don't know exactly what ratio is 'ideal',

True, but the IETF do, and they're the experts on Internet protocols. They designed TCP, and they've published an RFC that has become a Best Common Practice on how asymmetry impacts its performance.

If you read nothing else, read the following from the summary,

"Asymmetry, and particular high asymmetry, raises a set of TCP performance issues."

> especially given a swath of difference user types, but if we were to maximise bandwidth usage and 'altruistically' determine the rates, it definitely wouldn't be 1:1 >(symmetrical), perhaps not 18:1, but definitely somewhere inbetween given total bandwidth > 10Mbps or so (haven't sat down and figured it out exactly, but that is >probably ballpark given tcp overhead figures, ie for the download stream, and then whatever extra upload data is being sent).
>
>
>And then that's not to mention fiber typically 'has to be' symmetrical so theres really no administrative difference, or in fact its less burden leaving as is vs upload throttling (for whatever reason one might want to do that, and if that was even an issue).
>

>
>
>
>
>
>
>On Fri, Sep 13, 2013 at 9:47 PM, Mark ZZZ Smith <markzzzsmith at yahoo.com.au> wrote:
>
>
>>
>>
>>
>>----- Original Message -----
>>> From: Mark ZZZ Smith <markzzzsmith at yahoo.com.au>
>>> To: Tony <td_miles at yahoo.com>; "Beeson, Ayden" <ABeeson at csu.edu.au>; Guy Ellis <guy at traverse.com.au>
>>> Cc: "ausnog at lists.ausnog.net" <ausnog at lists.ausnog.net>
>>
>>> Sent: Friday, 13 September 2013 9:41 PM
>>> Subject: Re: [AusNOG] ADSL2+ line sync data
>>>
>>>  From: Tony <td_miles at yahoo.com>
>>>> To: "Beeson, Ayden" <ABeeson at csu.edu.au>; Guy Ellis
>>> <guy at traverse.com.au>
>>>> Cc: "ausnog at lists.ausnog.net" <ausnog at lists.ausnog.net>
>>>> Sent: Friday, 13 September 2013 9:55 AM
>>
>><snip>
>>
>>
>>>> If at 2000m you get either 18/1Mbps ADSL2+ or 11/11Mbps VDSL2 then thats
>>> fairly close to the same amount of total bandwidth (19 v's 22). This
>>> probably doesn't please the user though as they
>>> want faster downloads (to "obtain" the latest TV eps) and hence an
>>> option to choose which "DSL" you want might be of benefit depending on
>>> your intended usage of the link.
>>>>
>>>
>>> Sad thing about this is that doing that appears to be a good idea, but that
>>> actual best thing for performance is symmetry, due to how TCP uses ACK feedback
>>> to determine it's send rate. Congestion on the uplink, which is more likely
>>> to occur when the uplink bandwidth is lower than downlink bandwidth, will slow
>>> down downloads:
>>>
>>> BCP69/RFC3449, "TCP Performance Implications of Network Path
>>> Asymmetry"
>>> http://tools.ietf.org/html/rfc3449
>>>
>>>
>>>
>>
>>
>>I should add that Google gets it, which is why their FTTP is symmetric.
>>
>>http://googlefiberblog.blogspot.com.au/2012/04/construction-update.html
>>
>>
>>Q: I see a label on your diagram, “Gigabit Symmetric Fiber Connectivity.” What does that mean?
>>
>>
>>_______________________________________________
>>AusNOG mailing list
>>AusNOG at lists.ausnog.net
>>http://lists.ausnog.net/mailman/listinfo/ausnog
>>
>
>_______________________________________________
>AusNOG mailing list
>AusNOG at lists.ausnog.net
>http://lists.ausnog.net/mailman/listinfo/ausnog
>
>
>