Re: [apops] Re: [Oz-ISP] Telstra Community support

  • To: Phillip Grasso-Nguyen <grasso at magna dot com dot au>
  • Subject: Re: [apops] Re: [Oz-ISP] Telstra Community support
  • From: Joe Abley <jabley at automagic dot org>
  • Date: Sat, 14 Apr 2001 17:28:38 -0400
  • Cc: apops at lists dot apnic dot net
  • In-reply-to: <003d01c0c4fa$ad2512d0$6500a8c0@PGLAPTOP>; from grasso at magna dot com dot au on Sun, Apr 15, 2001 at 01:50:47AM +1000
  • References: <002e01c0c313$6897aee0$b4646fcb@PGLAPTOP> <v04220803b6fb25cbad63@[]> <002501c0c42b$ccbc1550$6500a8c0@PGLAPTOP> <> <006101c0c436$8af00e00$6500a8c0@PGLAPTOP> <> <003d01c0c4fa$ad2512d0$6500a8c0@PGLAPTOP>
  • Sender:
  • User-agent: Mutt/1.2.5i
    • On Sun, Apr 15, 2001 at 01:50:47AM +1000, Phillip Grasso-Nguyen wrote:
      > > The normal approach to routing around bottlenecks is to call your provider
      > > and say "hey! there's a bottleneck there. you should fix your export
      > > policy to avoid that."
      > <Telstra bashing>
      > [...]
      > </Telstra bashing>
      So change providers!
      > there isn't much choice of large enough
      > service providers in Australia.
      So move to New Zealand! :P
      There are a bunch of Australian operators who bought capacity on Southern
      Cross, and who now have it lit and carrying traffic. Surely you have some
      choice in this area?
      > > You are asking Telstra to offload the job of fixing their transit issues
      > > onto their customers. To some extent, this is similar to them just
      > > providing
      > > you with telnet access to their routers, and saying "if you need to make
      > > changes, go ahead" :)
      > Yes and No, Obviously the problem is not just with Telstra but with most
      > transit providers,
      I don't know about that.
      The essence of your problem seems to be "my transit provider isn't fixing
      my transit well enough to keep me happy, so I want knobs I can turn to
      fix it myself when I notice it is broken".
      If Telstra are exhibiting frequent congestion towards different locations,
      it suggests that their inbound traffic is quite finely balanced. That
      being the case, I can see why they don't go out of their way to allow
      customers to influence their inbound traffic -- a fix to your problem
      might cause a bigger problem for 100 other customers.
      > So how much more does it hurt to give your transit customers the option to
      > control beyond the next hop AS, how much more functionally without making it
      > difficult. I suppose if you really wanted to be difficult you could
      > implement the edge filtering with something similar to the old access-list
      > 112 by Sean Doran, but then we go back to the not knowing the true network
      > path, and black holing networks. - ( yes this someone also mention this in
      > "verio-style edge filtering").
      These all seem like good questions to ask Telstra. And if you don't get
      answers you like, surely you can take your business elsewhere :)
      > What about things that like,
      > - edge cache policy propagation? where a hosting provider decided to do
      > reverse transparent caching, being put on the cache or even off caching can
      > be achieved via simple community
      Aren't caches illegal in Australia, now? :)
      > - QoS policy propagation? where certain network traffic can be modified to a
      > high precedence or QoS group via communities, and on billing can be done via
      > Netflow?
      > obviously these things can be done already, but so much more can be done!.
      QoS is based on the premise that a small subset of customers will be willing
      to spend ten times more than others on the strength that they should get better
      performance for an hour a day, with the understanding that any performance
      improvement cannot be measured.
      I haven't seen anybody rush to deploy this yet, for some reason.
      # find / -name base -exec chown us:us {} \;
      *             APOPS: Asia Pacific Operations Forum              *
      * To unsubscribe: send "unsubscribe" to apops-request at apnic dot net *