Re: comments on requirements draft

[Peter Tattam <peter@jazz-1.trumpet.com.au>]

Presuming you are referrring to my preliminary draft.

The network level overhead is only require at setup and is cached at either
end.  Also the set of prefixes is quite compressible as it is actually more
like a tree.  If one strengthens the distinction between an full address and a
routing gook component, some of the concepts start to full into place.

I am currently working on an accompanying document which explores the
characteristics of transport level multihoming as it relates to my suggested
idea. I'm concerned also that the nomenclature (transport level multihoming)
doesn't properly convey the nature of the process.  I merely used the title
that Steve Deering used in his email probe to the list.

Peter

On Tue, 7 Aug 2001, Ramakrishna Gummadi wrote:

> Peter, 
> 	Just a thought on the amount of addressing overhead this would
> involve with transport-level multihoming: assuming each of your customers
> dual homes with any provider that is triply redundant, this means their
> network-level header overhead would be 16*3*2=96 bytes. This is not at all
> a pleasant thought if we consider the fact that the average packet size is
> about 500 bytes...
> 
> thanks,
> ramki
> 
> > I was at a recent conference in Aus and the issue of Service Level Agreements
> > was being discussed in a forum panel.  Each of three very large
> > telco's/provider's (by Aus standards anyway) representatives were all highly
> > confident that they could promise extremely high levels of redundancy and there
> > was no need to have more than one provider.
> > 
> > However by the end of the panel discussion and after several war stories were
> > shared by members of the audience and even one member on the panel, it
> > was eventually conceded that for an effective SLA, redundancy was crucial, and
> > in particular to multiple providers.  The forum concluded with an independent
> > consultant's reflection that they always recommended complete redundancy to
> > their clients especially at the last mile.
> > 
> > I also find that the further you are away from the core of the internet in your
> > region, the higher is the risk of things going bang.  We are multply homed to 3
> > providers even though we are a small ISP, and I have had occusion to depend on
> > each of them for large outages over the past year.  Some outages were
> > configuration problems in networks, while others were meltdowns in the
> > providers infrastructure including major cable breaks, and even one
> > international fibre break.  Had it not been for our multihoming, our service
> > would have been out for a minimum of several hours, and in one worst case
> > scenario we suffered, 2-3 days.
> > 
> > This risk of things going wrong being higher at the edge is a curious
> > observation as it flies in the face of the conventional wisdom that says that
> > the smaller you are, and further from the core, the less need one should have
> > for multihoming.  I would suggest the converse may actually be true.  The
> > smaller or perhaps more remote a site or network is, the higher is the risk
> > that the quality of their service is going to be degraded in one way or
> > another.
> > 
> > I guess my point is that to maintain any kind of quality of service, a small
> > provider has to go that extra mile (pardon the pun) and provide a better
> > service to differentiate their brand from the big providers.  One method of
> > differentiation is redundancy by multihoming, even if the perceived cost may be
> > high.
> > 
> > Peter
> > 
> > --
> > Peter R. Tattam                            peter@trumpet.com
> > Managing Director,    Trumpet Software International Pty Ltd
> > Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210
> > 
> > 
> > 
> 
> 

--
Peter R. Tattam                            peter@trumpet.com
Managing Director,    Trumpet Software International Pty Ltd
Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210