Subject: RE: AW: Differentiated Routing, not only plain rambo-SPF

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 24 Jul 2002 15:06:25 -0400

> -----Original Message-----
> From: Naidu, Venkata [mailto:[email-masked]]

> -> From: J. Noel Chiappa [mailto:[email-masked]]

> -> 
> -> You just hit one of my hot buttons.
> -> 
> -> Normal IP routing is not stateless. It has lots of state in 
> -> the network.
>   
>   Hummel is not talking about *state* in the network.
>   The information (in your words: a Header) required to 
>   route packets is state-less. Routing is purely based on
>   *destination* address. Isn't it?

But the routers must maintain state information, such as network topology (OSPF) or spanning tree (RIP). True, under default IP best-effort routing, routers do not need to maintain state information *per flow*. But in case of RSVP, they do. MPLS, per labeled path. Diffserv, per flow aggregate rather than per flow.

>   IMHO, just using DSCP bits on per-hop won't achieve 
>   QoS "Globally". You have to combine TE also.
>   That "QoS using TE" has been neglected by us.
>   That is what I am trying to convince Fred.

In my opinion, you need TE and you need _access control_ to achieve any credible QoS, no matter what scheme you use.

>   If you consider IP is a superset, MPLS, QoS and TE are
>   some overlapping subsets (pictorially):
> 
>        IP Superset
>        +-----------------------------------+
>        |     __________    __________      |
>        |    /          \  /           \    |
>        |   /   MPLS     \/    QoS      \   | 
>        |  /             /\              \  | 
>        | |             |  |             |  | 
>        | |             |  |             |  |
>        | |             |  |             |  |
>        | |          ___|__|___          |  |
>        |  \        /    \/    \        /   |
>        |   \      /     /\     \      /    |
>        |    \____/_____/  \_____\____/     |
>        |        |                |         |    
>        |        |                |         |
>        |        |                |         |
>        |         \      TE      /          |
>        |          \            /           |
>        |           \__________/            |
>        |                                   |
>        +-----------------------------------+
> 
>    You can just do MPLS (for fast label look-up etc).
>    You can achieve QoS using MPLS (without TE)
>    You can achieve better QoS using TE (with or 
>    without MPLS) etc etc...

I agree with the words you say above, but not the picture. Seems to me that QoS is a hoped-for result if you implement TE, MPLS, perhaps RSVP, perhaps Diffserv, and so on. QoS is not a technique, as MPLS and TE are. It is the result of using one or possibly several techniques.

>    IMHO, the intersection of all the subsets (ie., 
>    (QoS using MPLS-(DiffServ-Aware-TE) will make a 
>    *real-good* impact on end-to-end performance in the 
>    global Internet.

"Real good" would have to include access control (otherwise your QoS will go to hell anytime too many flows happen at an edge node, which can easily happen without controls on access) and also constraint-based routing (otherwise, the network will be apt to block new QoS service requests just because one possible route out of many might be temporarily congested). If the network core is assumed to be so fast that none of this is a concern, then the hope is that contraint-based routing is not so essential. I think that's where many of these QoS solutions seem to go. It gets "too hard" to do a complete solution. And a complete solution starts looking oh so similar to ATM.

Bert

_______________________________________________
routing-discussion mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/routing-discussion

---

From: Magnus Danielson <[email-masked]>
Date: Fri, 26 Jul 2002 18:17:49 +0200 (CEST)

Hi,

> >   *destination* address. Isn't it?

Nothing is purely stateless. The whole issue of the statelessness of IP (the
protocol or the suite of protocols is nowdays important to distinguish between)
is IMHO a historic relic. The real issue is how much state there is, where it
is and how we create and maintain it. The old scare of seeing state per flow is
still valid, since the number of flows on a large internet like the IP Internet
is very large, and this translates into a hell of a lot of memory and
processing. Since then it has been a debate on how best to cut and slice the
turkey into feasable chunks, even if it has not been spelled out.

> But the routers must maintain state information, such as network topology (OSPF) or spanning tree (RIP). True, under default IP best-effort routing, routers do not need to maintain state informatio…

Right. Question is, of all the methods, what actually works all the way?

> In my opinion, you need TE and you need _access control_ to achieve any credible QoS, no matter what scheme you use.

Rather, if you are to guarantee a certain QoS, you need both to identify the
QoS needed, and means to within the network realize this. If you only have the
QoS requirement "fire and forget" then surely you do not need access control,
but the trouble comes when you want all of your transmitted bits to appear in
both good time and right order at the receiver(s), then you are really asking
for an allocation, and with allocations comes the need to limit these in order
to still ensure the service, and with that comes the need for policing and
this in turn put requirements on the transmitter and receiver sides in the
interaction with the network. Access control (actually, Call Access Control,
which is the right term in this scenario) is where this lead us. With such
strict interpretation of guarantees, we have allocation and thus "hard state"
(and not the so belowed "soft state").

In reality, I think that you can never avoid the hard guarantee and thus hard
allocation, nothing actually replaces it. However, hard guarantees is not
everything in a packet based network like the Internet.

The benefit of hard allocations is that the network now knows what to expect
from that part of the traffic. Just forget you had that capacity available.
This simplifies the Traffic Management and Traffic Engineering.

This is somewhat of a side-track, but I really think you can't acheive a full
system solution unless you first separate out the need for end-to-end strict
allocations and then deal with the rest. People tend to argue from very
different standpoints unless you do this.

> I agree with the words you say above, but not the picture. Seems to me that QoS is a hoped-for result if you implement TE, MPLS, perhaps RSVP, perhaps Diffserv, and so on. QoS is not a technique, a…

Actually, QoS is defined to be a set of measures of the acheived Quality of the
service. Whatever techniques we put into use, they are there to somehow help
improve those measures, at least for the traffic which have a higher
requirement than other traffic.

If no diffrentiation in requirement between two sets traffic of traffic is
found, then they compete on the same level.

This whole soup is naturally complex, bitter-sweet and potentially leathal.

> "Real good" would have to include access control (otherwise your QoS will go
> to hell anytime too many flows happen at an edge node, which can easily
> happen without controls on access) and also constraint-based routing
> (otherwise, the network will be apt to block new QoS service requests just
> because one possible route out of many might be temporarily congested).

Again, blocking or not depends on which QoS goal you are attempting to acheive.
If you want strict guarantees you want yo be your own flow and you really want
your own capacity. This is when you want blocking. When you reach congestion
you have several methods to cope with it, like premtion by priority or by
having pushback mechanisms allowing thus that allows to be pushbacked to a
lower capacity do this in a controlled maner. When such measures fails,
blocking is what you want to get, since you could not aquire the guarantee you
requested.

You can then invent other softer allocation schemes, where blocking is not an
option, but where you never the less can get different treatments. Just
separating the treatment of normal TCP and that of UDP/RTP springs to mind.

> If the network core is assumed to be so fast that none of this is a concern,
> then the hope is that contraint-based routing is not so essential. I think
> that's where many of these QoS solutions seem to go. It gets "too hard" to
> do a complete solution. And a complete solution starts looking oh so similar
> to ATM.

Right, but on the same time one has to realize that it is not all about tossing
packets on this or this queue etc. The issue of time is really important too.
In ATM they had to synchronise the switches. Real-time traffic have (almost) by
definition tough requirements on the timing QoS measures, and this have
implications to how we route and handle the traffic, especially in relation to
other ("non-realtime traffic"). In reality we have a form of
pseudo/soft-realtime traffic (i.e. Web, FTP, Telnet/SSH, DNS) in addition to
hard realtime traffic (i.e. Audio/Video).

Also, for part of the traffic, there are requirments are allways end-to-end and
if a solution for that traffic is to exist on the Internet, then the solution
must work end-to-end, even if this will hurt in many places.

Sorry for this sidetrack, but IMHO it is often forgotten. Please continue with
this interesting thread.

Cheers,
Magnus

---

From: Magnus Danielson <[email-masked]>
Date: Fri, 26 Jul 2002 18:17:49 +0200 (CEST)

Hi,

Cheers,
Magnus