[AusNOG] TPG Peering

Wed Oct 22 07:17:17 EST 2014

I think you'll find most games are using UDP, and TPG's peering being
saturated is either causing very high latencies, or lost packets.  Either
way, it wouldn't be making for a good gaming experience..

It's funny you mention Apple updates.  My work peers directly with Apple,
and at 2pm on the day of the Yosemite release, I was getting 200kbytes/sec
from them - I'd have loved to see their bandwidth graphs that day ;)

I don't know if thinking has changed since I was at uni, but 70% of link
utilisation is the point at which Latency increases beyond a reasonable
level, so is what should be considered 'Full utilisation' in an operational
sense.

On 22 October 2014 06:59, Mark ZZZ Smith <markzzzsmith at yahoo.com.au> wrote:

>
>
>
>
>
> >________________________________
> > From: Jared Hirst <jared.hirst at serversaustralia.com.au>
> >To: Bob Woolley <boblobsta at gmail.com>
> >Cc: "ausnog at ausnog.net" <ausnog at ausnog.net>
> >Sent: Tuesday, 21 October 2014, 20:41
> >Subject: Re: [AusNOG] TPG Peering
> >
> >
> >
> >Because generally they wont direct peer. We are trying to send them 500+
> mbits though and when it's congested this is causing issues for us and
> their users.
> >
> >
>
> Is it really causing issues for their users?
>
> One thing to bear in mind is that TCP attempts to utilise what ever
> bandwidth is available at the time, which is quite reasonable as a design
> goal, because the network has been "100% paid for" so why not try to use
> 100% of its capacity when ever possible? Multiple TCP connections over the
> same path should back off such that the available bandwidth is roughly
> equally shared between all of them.
>
> However, when it comes to what is actually being delivered over that TCP
> connection, aiming for 100% network utilisation may not be necessary when
> the data is being delivered for a human. If the data is 'bulk' data e.g., a
> large file download, once the total time it takes to download goes past a
> human's longer term focus attention span, IOW, the time that they're focus
> on watching it occur, then the total time it takes is less important.
> Consequently, allowing congestion to occur over paths that these types of
> TCP connections are taking isn't necessarily as bad as it appears. The only
> consideration then would be how is congestion impacting latency sensitive
> applications also operating over that congested link. If you have none of
> those, then the congestion is far less harmful, as long as the large
> downloads arrive within a reasonable time (and a reasonable time seems to
> be in multiples of hours).
>
> For example, if the recent IOS 8 update was going to take 45 minutes to
> download over a congestion free link, but 60 to 75 minutes over a congested
> link, I don't think many if any people would either care and notice.
>
> I don't know of studies that show where the 'focus attention switch'
> threshold is for large downloads, however I think it is only in the order
> of a few minutes - the time where you start the download and then switch
> away from observing it and start doing something else e.g., start web
> browsing, making a coffee, got to watch TV etc. If there isn't a prediction
> shown as to how long it takes, then I think people tend to check every 5 to
> 10 minutes, and perhaps increase their checking interval if progress isn't
> significant e.g., start checking once every 15 minutes, then 30 etc. After
> that, if progress still isn't quick enough, then people will leave it
> running without checking for many hours, and perhaps overnight.
>
> I think this further shows that latency is more important to humans than
> bandwidth/throughput. IOW, we desire instant gratification, or as near to
> it as we can achieve or pay for, and continue to be motivated to get closer
> to instant gratification (the cliché "patience is a virtue" is
> fundamentally advice to try to suppress these instant gratification
> desires).
>
> People who want high bandwidth/throughput so their downloads have short
> completion times are actually still saying latency is more important to
> them - they want lower *latency*[1] downloads. Whether that is a realistic
> expectation or not depends on how much they're willing to pay. As TPG
> customers would typically be more price sensitive, it would be reasonable
> for them to have to accept higher latency "anything" than those of other
> higher price/quality ISPs.
>
> So in summary, if the content you're sending TPG is 'bulk', then
> congesting over links towards them may not be as much of a problem as it
> appears. If it is a problem, TPG's customers will or should be ringing the
> TGP helpdesk to complain about it. That is where the cost of this
> congestion is to TPG. If TPG don't care about their customers, those
> customers will find a better ISP. If TPG do care about those customers,
> then TPG should be more willing to come to an arrangement (which might
> include private peering) that eliminates the congestion associated helpdesk
> costs.
>
> [1] https://en.wikipedia.org/wiki/Latency_(engineering)
>
> >
> >
> >
> >On Tue, Oct 21, 2014 at 7:27 PM, Bob Woolley <boblobsta at gmail.com> wrote:
> >
> >Why should that be a long shot?
> >>because tpg don't like networking with others
> >>
> >>
> >>- Bob W
> >>
> >>
> >>
> >>On 21 October 2014 18:18, Mark Newton <newton at atdot.dotat.org> wrote:
> >>
> >>
> >>>
> >>>On Oct 21, 2014, at 10:50 AM, Jared Hirst <
> jared.hirst at serversaustralia.com.au> wrote:
> >>>
> >>>Looking to talk to someone about peering direct with TPG (I know it's a
> long shot) but the issue is that everday between 6-9pm we see congestion to
> TPG, upon looking at their PIPE port we can see it's maxed at 20 gbits, and
> hence this would be causing our issues.
> >>>
> >>>Why should that be a long shot? Sounds like precisely the kind of thing
> that’d justify a private peering relationship.
> >>>
> >>>
> >>>  - mark
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>_______________________________________________
> >>>AusNOG mailing list
> >>>AusNOG at lists.ausnog.net
> >>>http://lists.ausnog.net/mailman/listinfo/ausnog
> >>>
> >>>
> >>
> >
> >
> >
> >--
> >
> >Jared Hirst
> >Chief Executive Officer
> >Office Address: 2/2 Teamster Close, Tuggerah NSW 2259
> >Postal Address: PO Box 3187, Tuggerah NSW 2259
> >Phone: +61 2 8115 8801 | Network Ops: +61 2 8115 8850 | Main Switch: +61
> 2 8115 8888
> >Web: www.serversaustralia.com.au
> > How are we doing?
> >please click here to tell Servers Australia - We‘re listening
> >Notice: This message may contain private and confidential information
> intended only for the recipients. If you have received this message in
> error please delete immediately and notify the sender, as any distribution
> or reproduction of this message is prohibited. The views & opinions
> expressed in this e-mail are NOT necessarily those of Servers Australia
> >Please consider the environment before printing this email - every year
> we are losing 40 million acres of oxygen producing forests through logging
> and land clearing.
> >
> >_______________________________________________
> >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
>

-- 

Damien Gardner Jnr
VK2TDG. Dip EE. GradIEAust
rendrag at rendrag.net -  http://www.rendrag.net/
--
We rode on the winds of the rising storm,
 We ran to the sounds of thunder.
We danced among the lightning bolts,
 and tore the world asunder
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20141022/b06a5b23/attachment.html>