Hi Xingang,
I'm not really in a position to comment on IP QoS strategies.
All I can state is that my belief is that QoS relies on
2 things:
* End to end support of QoS within the network.
* Interoperable standards between vendor equipment.
You may know that in the past ATM networks suffered because
of a lack in either of these areas. I believe though that
this was symptomatic of early development of the technology.
Similarly, providing IP QoS is something which is still evolving.
This does not prevent subsets of the Internet from developing
forwarding gurarantees and policies in anticipation of these
developments, but I believe the IETF's traffic engineering,
diffserv and mpls working groups are working on such issues now.
Greg
Xingang Liang wrote:
>
> Ok,Let's look at the problem in another way!
> Just as Greg said,the connectionlessness of IP takes a lot of advantages than
>ATM,which is connection-oriented,I agree with this point!
> But when you compare the flexibility,you should remember whatever network you
>use,the service that they provide is the most important!
> Even though ATM is not as flexible as IP, it can provide a guaranteed QoS,while can
>IP provide the same QoS?
> Perhaps someone will say there are many solutions to strengthen the IP QoS,such as
>RSVP,Diffserv,and so on.
> But implementing these solutions in IP network may be a more complexible thing!
> When we send a packet outward,we don't know the path it takes.We don't know whether
>there are routers that don't support RSVP or Diffserv,
> we don't know whether there are ATM switches on the path,we don't know whether there
>are other types of networks on the way!How should we
> provide the QoS using IP?One way is that we strengthen the network to guarantee
>every node supports for specific QoS solutions!How about guaranteeing ?
> Just like RSVP:before we send the data packet,we first use the RSVP packet to find
>the right path!The other way is that since we can't guarantee the middle path,we can
>do something in end applications to guarantee the QoS,for example,we can configure
>the packet-sending procedure to be finished until we receive reply from the other end
>node.But whichever way you take,won't you find them more complexible???
> Network is stupid,it just provides transportation like service that is simple!we
>can't demand too much from it!
> I don't mean that we should use ATM,not IP.I just want to find out when we design or
>choose a protocol as a widespread acceptance,what features we should pay attention to
>and what criterion we should take.ATM,IP and what is the future after IP?
> Welcome any comments and say sorry to those whom I bothered with my question!
>
> Xingang
> BR
>
> ----- Original Message -----
> From: "Greg Daley" <[EMAIL PROTECTED]>
> To: "Brian E Carpenter" <[EMAIL PROTECTED]>
> Cc: "Xingang Liang" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> Sent: Thursday, October 18, 2001 3:05 PM
> Subject: Re: ATM,IP, and the Future!------send again with plain text!
>
> > Brian E Carpenter wrote:
> > >
> > > We can say it another way - ATM is a point-to-point technology tied to
> > > specific types of hardware. IP is an end-to-end technology that is
> > > independent of types of hardware. These are simply different roles.
> > > ATM will continue to be used, for example, between IP routers inside
> > > carrier networks. But it is IP that carries data from computer to computer,
> > > running across Ethernet, ATM, modems, and many other hardware layers
> > > on the way. That is why IP (especially IPv6) is the future.
> > >
> >
> > I think it is important to remember that ATM is a network too,
> > like IP, and is not just a link technology.
> >
> > Functionally, though, I think that the issue is more one of
> > "connection oriented" to "connectionless". The flexibility of
> > the connectionless packet switched network has allowed existing
> > media to be used at the link layer.
> >
> > In many cases, this has allowed IP's uptake where ATM has not
> > been able to be deployed.
> >
> > Greg Daley
> >
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page: http://playground.sun.com/ipng
> FTP archive: ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to [EMAIL PROTECTED]
> --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
