[AusNOG] ADSL2+ line sync data

[Mark ZZZ Smith]

>________________________________
> From: Joshua D'Alton <joshua at railgun.com.au>
>To: Mark ZZZ Smith <markzzzsmith at yahoo.com.au> 
>Cc: "ausnog at lists.ausnog.net" <ausnog at lists.ausnog.net> 
>Sent: Sunday, 15 September 2013 2:34 PM
>Subject: Re: [AusNOG] ADSL2+ line sync data
> 
>
>
>Might be lazy sunday afternoon messing with my comprehension, but in the former case they'll have ~4.6Mbps spare upload capacity, in the later 24.6Mbps. Neither are full rate, if I read you correctly, though in the later case it is 98.5% line rate vs 92% which might be a noticable difference, probably not in terms of time for something to upload (less than 10% difference), but maybe for capability itself to upload (ie maintaining full stream video conference or doctors etc). 
>
>
>But really I doubt anyone would notice, especially given speedtest doesn't use both at the same time. In fact I think more people would complain about actual performance (ie why don't i get 25Mbps from some remote server, or hell even youtube/akamai/CDN cache locally), than the few that would fire up uTorrent, download a linux iso and think "oh hey, 25mbps down, but only 4.6mbps up in the status bar, why isn't that 5mbps!?!". Not to mention everyone already just says "up to", both for line rate reasons, and for aforementioned remote site/connectivity bottleneck being causes for not seeing maximum advertised speeds.
>

Why is it acceptable to not be able provide what is being sold? Just because some people don't realise they're not getting the service they're paying for, I don't think that means it is acceptable to continue to sell a service that cannot actually be delivered.

>
>I could be wrong but I think you've shifted a bit away from ietf best practice reasons to have symmetry, towards the fact people actually need more upload full stop, symmetry being a happy coincidence.

No, I have not shifted away from the IETF BCP. People need so much "upload" that it equals their "download".

The thing you seem to be missing is it isn't the type of service or the type of user that dictates whether asymmetry will cause problems, it's whether TCP is being used or not. Since TCP is used by everybody, whether it's a residential or business service doesn't matter. *All* user or customer types will benefit from symmetry, unless they don't use TCP.

Assuming residential users will only download is ignoring the reality that people are doing things like uploading large photos and videos to facebook, flickr, youtube etc., and video conferencing with their relatives or their doctor or other professionals. If the "NBNs" of either party don't recognise this, then they're not as revolutionary or evolutionary as they and the general population think. These NBNs are going to constrain end-users to primarily being consumers of content rather than equally being possibly both consumers and producers, or being producers more than consumers.



> Which I'd agree with, though not that symmetry is required/very.important for customer expectation/relations reasons. 
>
>
>Anyway I originally said "not very applicable", and it seems we're all talking about the fringe cases where it IS infact much more applicable, so if we stepped back into the realm of averages and normal use cases.. Given the choice between higher download and symmetry, the very fact that most connections are used to consume data and not create data should and does lead towards asymmetry and will remain that way even with datacenters in basements and 4K cat streaming.
>
>
></arguing>
>
>
>
>
>On Sun, Sep 15, 2013 at 1:56 PM, Mark ZZZ Smith <markzzzsmith at yahoo.com.au> wrote:
>
>
>>
>>So if a customer buys a 25/5 service for example, they'd expect that they'd be able to upload at 5Mbps while also downloading at 25Mbps. They probably won't be able to due to bandwidth asymmetry, which means that the ISP/RSP may be violating trade practices laws for false advertising. Or in the least, the ISP/RSP have to deal with customer complaints.
>>
>>OTOH, if the ISP/RSP provided 25/25, then it is possible to both upload and download using TCP at full rates in both directions.
>>
>
>