Subject: [Architecture-discuss] QoS guarantees (RE: Mobility and multi-homing)

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 02 Nov 2005 16:57:47 +0100

--On torsdag, oktober 27, 2005 19:02:13 -0400 "Bound, Jim" 
<[email-masked]> wrote:

> Can guranteed QoS be achieved end-to-end and we have so many views on
> this and the current work and results from Diff and Int serve are not
> good enough by themselves, what is the answer?

Branching discussions is so much fun :-)

my opinion, which is not worth much:

Guarantee is an illusion. No matter how much you pay for "guaranteed 
bandwidth", I'm not going to issue guarantees against a dinosaur-killer 
asteroid landing on my NOC 10 years from now.

The question we SHOULD be asking is whether diffserv and/or intserv gives 
us the tools we need to do:

a) let the net-provider state to the customer what he can expect from the 
network (at an appropriate level of confidence)

b) let the customer state to the net-provider what he wants from the 
network (and the level of confidence he needs)

c) let the net-provider(s) keep track of what they have promised in the 
aggregate, and know whether or not he's able to deliver on his promises at 
any given time.

Note that a) and b) can occur in any order, including ababababab.... that's 
called "negotiation".... and I'm sure that some people will claim that the 
answer to c) is "MPLS", whereas others will say "if the answer is MPLS, you 
have misunderstood the question".....

_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss

---

From: Pekka Savola <[email-masked]>
Date: Wed, 2 Nov 2005 19:39:28 +0200 (EET)

On Wed, 2 Nov 2005, Harald Tveit Alvestrand wrote:
> --On torsdag, oktober 27, 2005 19:02:13 -0400 "Bound, Jim" <[email-masked]> 
> wrote:
....
> asteroid landing on my NOC 10 years from now.

If folks really want this, I'd start off by answering the question:

  What's in it [guaranteed e2e QoS] for me?

   [substituting 'me' for all the ISPs in the end-to-end path]

Now, getting on my operator soap box...

It should be pretty evident that e2e guaranteed QoS is basically a 
non-starter as long as it isn't tied to a money routing protocol.

IMHO, the path-coupled signalling (nsis) that the IETF has been 
working on has very limited applicability (first hop router or 
internal enterprise network only).  That's way too much (slow path, 
only, accounting, etc.) processing for routers, on each hop.  A saner 
approach would be a complete path-decoupling, where dedicated boxes 
would be contacted for negotiating guarantees (and those boxes would 
propagate QoS configs on the required routers as needed).

> network (at an appropriate level of confidence)
....

   d) let the user easy determination which applications at which times
      (s)he would like to get a good guarantee -- and which ones the
      user doesn't care all that much about.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Fred Baker <[email-masked]>
Date: Wed, 2 Nov 2005 11:52:13 -0800

If you sell an SLA that mentions bandwidth, and AFAIK most ISPs do, I  
think you'll agree that the SLA is not against dinosaur-killing  
asteroids. It is about the service you will deliver to a specified  
customer during a finite period of time at a cost under normal  
conditions. I'd really suggest that if we want to have this  
discussion, we don't branch into put-downs and hyperbole. It doesn't  
help.

You have two levels of guarantees under discussion here. One is the  
base SLA - "you pay me $$$ and I will deliver <MBPS with lots of  
other attributes>". That is the state of play today. Those who are  
discussing integrated services negotiation at a finer level are  
discussion something related-but-different. "Given that you are  
delivering <SLA>, I intend to use part of it for a real-time service  
that doesn't adapt or has at most limited ability to adapt to the  
network, and you have agreed to support up to <SLA'> of that on my  
behalf. If I add an additional session with <flowspec>  
characteristics, would I still be within <SLA'>?" The "guarantee"  
relates to the network's ability to deliver a service to an inelastic  
application within a larger SLA at a time, and presumably at a cost  
or within a budget paid in another way.

Where this becomes important is places where congestion does in fact  
set in, as opposed to places where effectively-infinite bandwidth is  
the rule. Within ISPs located within the better-funded parts of the  
world, and to a less extent between those ISPs, we deploy sufficient  
bandwidth that there isn't a lot of question. Ditto on LANs, which is  
to say "within campuses". Effectively-infinite bandwidth has yet to  
make it to relatively large parts of the world, however, and that  
includes access networks like the one attached to the other end of my  
house. Something that affects that is services offered to a user,  
especially when they have different privilege levels. That is the  
place of discussions like ieprep is having.

On Nov 2, 2005, at 7:57 AM, Harald Tveit Alvestrand wrote:

> Guarantee is an illusion. No matter how much you pay for  
> "guaranteed bandwidth", I'm not going to issue guarantees against a  
> dinosaur-killer asteroid landing on my NOC 10 years from now.
>
> The question we SHOULD be asking is whether diffserv and/or intserv  
> gives us the tools we need to do:
>
> a) let the net-provider state to the customer what he can expect  
> from the network (at an appropriate level of confidence)
>
> b) let the customer state to the net-provider what he wants from  
> the network (and the level of confidence he needs)
>
> c) let the net-provider(s) keep track of what they have promised in  
> the aggregate, and know whether or not he's able to deliver on his  
> promises at any given time.
>
> Note that a) and b) can occur in any order, including  
> ababababab.... that's called "negotiation".... and I'm sure that  
> some people will claim that the answer to c) is "MPLS", whereas  
> others will say "if the answer is MPLS, you have misunderstood the  
> question".....
>
>
>
>
>
>
>
>

--------------------------------------------------------------
"Don't worry about the world coming to an end today. It's already  
tomorrow in Australia." (Charles Schulz )