Re: [Diffserv] QoSSIG BOF

Bob Braden <> Mon, 24 January 2000 21:02 UTC

From: Bob Braden <>
Date: Mon, 24 Jan 2000 21:02:43 +0000
Subject: Re: [Diffserv] QoSSIG BOF
Message-ID: <>

  *> From Mon Jan 24 01:40:50 2000
  *> From: (Lars Westberg T/NI 2)
  *> Date: Mon, 24 Jan 2000 10:40:39 +0100 (MET)
  *> To:,, braden@ISI.EDU
  *> Subject: Re: [Diffserv] QoSSIG BOF
  *> Cc: rsvp@ISI.EDU,, end2end-interest@ISI.EDU,
  *> X-Sun-Charset: US-ASCII
  *> Content-Length: 1338
  *> X-Lines: 34
  *> Hi!
  *> We have a need for a low cost solution, but our problem is not 


I would like to understand what you are saying.

"Low cost" in terms of what metric?  And what are the economic imperatives
that require "low cost"?

  *> end-to-end. We would rather like to solve a intra-domain solution 
  *> or edge-to-edge solution.

I don't get how you plan to bridge the gap between the ultimate end users --
the folks who want to make telephone calls -- and your network edges.
Is there to be a different signaling protocol for the edges?  The
same, or a different one, between administrative domains (sounds
awfully like X.25 and X.75, doesn't it?)

  *> Our need is much simplier than solving reservation
  *> from a host-to-network or between different administrative domains.
  *> Our edge could be an edge-router or gateway.

But you agree that *somebody* has to solve "reservation
from a host-to-network or between different administrative domains"?
If the pieces are separately designed, how do you see their fitting

 *> We are assuming that this method should be a complement to the QOS-tool-box
  *> for some dedicated networks with certain characteristic and not for all kinds 
  *> of networks.

I am not sure what this means.  Could you elaborate?

  *> We are mostly interested of QOS for Real-time traffic such as voice.

Curiously, this is exactly the reason behind the int-serv/RSVP development,
while diffserv is mostly after a different problem.

  *> Our basic problems are:
  *>  * High volume of speech-traffic. The reservation scheme has to support up to
  *>    70-90% of voice traffic.

You don't believe people will use the communication facilities for anything
but voice? No online shopping?  

  *>  * Edge-to-edge reservation within one adminstrative domain, not end-to-end.
  *>  * Mobility. Our traffic is moving between different areas in the network.
  *>    semipermanent trunk allocation implies need for more transmission and
  *>    O&M. Cost for operation and maintenance might be the biggest issue. 

Sorry, I didn't quite understand this.

  *>  * Fast reservation. The time between request and acknowledgement
  *>    of the reservation should be in the order of the forwarding delay.

You have not mentioned multicast, which is the primary reason for RSVP
complexity.  Do you believe in multicasting?


Bob Braden

  *> We have as well a draft (a marker based scheme, you can find it in the library) 
  *> but I would be very interested to get other proposals from other peoples.
  *> Regards Lars Westberg
  *>         Ericsson Research

----- End Included Message -----