The IP over ATM Mailing List Archive by date

[Philippe Oechslin <oechslin@lrc.epfl.ch>]

Jon, 

J.Crowcroft@cs.ucl.ac.uk said:
> thats what i am proposing - not another family of socktes, but just 
> of dadresses

> sockaddr_arequpa = (string form" ipaddr+atmaddr+qos

> then the API is unchanged, and applications just connect, or bind, on 
> these new addresses 

ok, I got you now. What you are proposing is an api that looks like the 
standard socket api but allows to add QoS functionality (eg. Arequipa or RSVP).

Basically you pass extra information through the usual calls, instead of 
adding extra calls. You'll have to modify your application anyway to make use 
of the extra information.

The use of either API doesn't change the functionality you get from the 
underlying QoS mechanism, be it RSVP or Arequipa. 

I don't favor either solution. Is there any consensus on what type of API 
will/should be used with RSVP?


J.Crowcroft@cs.ucl.ac.uk said:
> oh, i see - its a two phase thing - but what about call setup latency 
> - surely for many things you might want to use this for (e.g. 
> performant web access) this would be too slow?

In the Web example my assumption is that the QoS depends on the document you 
are downloading, and that the client first wants to decide whether he is 
able/willing to use that QoS. 

If you always accept to use the QoS given by the document or if you decide of 
a QoS indepently of the document, you don't need two phases. You send your ATM 
address with the HTTP request and the server sends the document back using 
Arequipa, without asking you if you want so. 

  cheers,
  
    Philippe

--
oechslin@di.epfl.ch