Re: [Diffserv] QoSSIG BOF

[Bob Braden <[e-mail]>]

  *> From [e-mail] Mon Jan 24 01:40:50 2000
  *> From: [e-mail] (Lars Westberg T/NI 2)
  *> Date: Mon, 24 Jan 2000 10:40:39 +0100 (MET)
  *> To: [e-mail], [e-mail], [e-mail]
  *> Subject: Re: [Diffserv] QoSSIG BOF
  *> Cc: [e-mail], [e-mail], [e-mail],
  *>         [e-mail]
  *> 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 

Lars,

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
together?

 *> 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?

Thanks,

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 -----