Subject: [NSIS] Looking back at RFC 1633

From: [email-masked]
Date: Fri, 5 Apr 2002 10:56:02 +0200

Dear all, 

I just reread RFC 1633. It was very interesting reading and for those on the nsis-list that haven't read it during the last years I suggest you do. 

It's very interesting to read remarks like "there is an inescabable requirement for routers to be able to reserve resources... This in turn requires flow-specific state in the routers" and "We take the view that there should be a single service model for the Internet". One can ask oneself, has anyone of these statements truly changed? It's even more interesting to think of in conjunction with (pure) diffserv where neither of these are true.

To my main point though, there are 6 points I could find that ought to be interesting to discuss in regards to NSIS. These are either listed as further work, or in one instance I found the text to be vague. [Please, if you choose to respond to this email, alter the header so it is clear which one of the six points you are addressing]

1) Usage Feedback. 
"Another important issue in the service is the model for usage feedback, also known as accounting...", "this is a highly contentious issue, and we are not prepared to say more about this at this time". 

Have we collectively learned more about what "accounting"-models to support today so we can determine what the requirements truly are? 

2) Reservation model
"The 'reservation model' describes how an application negotiates for a QoS level.", "Further work is needed to define the amount of generality, with a corresponding level of complexity, that is required in the reservation model."

Once again, have we learned more on this issue, or are we still at a point where we do not know the answer? I see people asking for very complex models and others (such as myself) that states that a yes/no reply is enough. 

3) Flow Id (under section 4.1.3)
"One approach to reducing the overhead of classification would be to provide a 'flow-id' field in the Internet-layer packet header... There are a number of variations of this concept, and engineering is required to choose the best design."

Have we learned what is the best design? Or at least a reasonable good design so we can get it deployed? Another related question, do we need a definition of "flows" in NSIS? 

4) Receiver initiation
"... For simplicity and economy, a setup protocol should support only one direction of       initiation, and, and receiver initiation appears to us to be the clear winner."

I know there were some discussions on this topic at the IETF, but I find it good to re-iterate this again. Is receiver initiation still the clear winner? [for those who jump up a scream an immediate no, please pay attention to multicast... :-)] And, does the accounting-model have any impact on the reservation initiation direction? 

5) Routing and reservation
"Some have suggested that reservation setup necessarily requires route set up, i.e., the imposition of a virtual-circuit internet layer.  However, our goal is to simply extend the Internet architecture, not replace it.".

I see (once again) some folks at the NSIS list advocating that a route set up or VC-like mechanisms is necessary. With our current knowledge, is there substansial reasons to change the conclusion of Braden et al? 

(in later chapters) 
"It may eventually be possible to fold together the routing and reservation setup problems, but we do not yet understand enough to do that."

Do we understand this issue better today? (this is perhaps somebody elses problem... irtf-rrg?). 

6) Mobility
"The last routing-related issue is provided by mobile hosts.  Our conjecture is that mobility is not essentially different from other route changes, so that the mechanism suggested ... will suffice.  More study and experimentation is needed to prove or disprove this conjecture." 
 
Have somebody been able to prove or disprove this conjecture?

best regards, 

Anders
ps, 
one issue I deliberately left out was the most obvious: "We conclude that there is an inescapable requirement for routers to be able to reserve resources, in order to provide special QoS for specific user packet streams, or "flows".  This in turn requires flow-specific state in the routers,", with Frank Kelly's and others work - is this true today, or can we do something much simpler? Or is reservations simply a dead end... 
psps I know we have touched on some of these issues, but I do not see them as resolved.

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

---

From: Roland Bless <[email-masked]>
Date: Mon, 08 Apr 2002 22:32:12 +0200

Hi Anders,

> It's very interesting to read remarks like "there is an inescabable
> requirement for routers to be able to reserve resources... This in
> turn requires flow-specific state in the routers" and "We take the
> view that there should be a single service model for the Internet".
> One can ask oneself, has anyone of these statements truly changed?

IMO after considering all the DiffServ work: Yes.
Refering to the first point:
In fact, DiffServ routers are not required to reserve resources.
Bookkeeping of resources can also be done by other dedicated entities
such as Domain Managers/BBs, thus removing resource management and signaling
burden from routers. However, routers have to be configured, but only
"first-hop routers" (or sometimes also "last-hop routers") per micro-flow.
Boundary routers usually have only profiles per aggregates and interior
routers normally don't need profiles (they have a rather static configured 
resource partitioning for their PHBs) and thus no flow-specific states.
Second point:
While it may be really important to have globally well-known services
in the future, it is a good idea to let those things evolve by market
demands etc. For the near future, it makes perfectly sense that ISPs
provide their own locally defined services to their customers at first,
because of easier management.

> It's even more interesting to think of in conjunction with (pure)
> diffserv where neither of these are true.

> To my main point though, there are 6 points I could find that ought to
> be interesting to discuss in regards to NSIS. These are either listed
> as further work, or in one instance I found the text to be vague.
> [Please, if you choose to respond to this email, alter the header so
> it is clear which one of the six points you are addressing]

I'll take all six... :-)

> 1) Usage Feedback.  "Another important issue in the service is the
> model for usage feedback, also known as accounting...", "this is a
> highly contentious issue, and we are not prepared to say more about
> this at this time". 

> Have we collectively learned more about what "accounting"-models to
> support today so we can determine what the requirements truly are? 

This is still difficult. But NSIS should be flexible enough to
let those things evolve indepently and thus it should provide hooks 
for an AAA architecture, so that reservation requests can be authenticated 
and accounted.

> 2) Reservation model "The 'reservation model' describes how an
> application negotiates for a QoS level.", "Further work is needed to
> define the amount of generality, with a corresponding level of
> complexity, that is required in the reservation model."

> Once again, have we learned more on this issue, or are we still at a
> point where we do not know the answer? I see people asking for very
> complex models and others (such as myself) that states that a yes/no
> reply is enough. 

As I already stated: NSIS should support negotiation of
service parameter _values_, which can be easily supported by a 
simple request/response dialogue when the response can also contain
a service object with the negotiated parameter values.
Service or service parameter negotiation can be added later by
specialized negotiation protocols.

> 3) Flow Id (under section 4.1.3) "One approach to reducing the
> overhead of classification would be to provide a 'flow-id' field in
> the Internet-layer packet header... There are a number of variations
> of this concept, and engineering is required to choose the best
> design."

> Have we learned what is the best design? Or at least a reasonable good
> design so we can get it deployed? Another related question, do we need
> a definition of "flows" in NSIS? 

I think DiffServ also provides the answers here. In the data path, we
don't really need a flow-id field. However, in the control path we
need the definition of a flow (at least when we want to support
micro-flows with end-to-end QoS). Therefore, we specifically must pay 
attention to scalability in the control plane.

> 4) Receiver initiation "... For simplicity and economy, a setup
> protocol should support only one direction of       initiation, and,
> and receiver initiation appears to us to be the clear winner."

> I know there were some discussions on this topic at the IETF, but I
> find it good to re-iterate this again. Is receiver initiation still
> the clear winner? [for those who jump up a scream an immediate no,
> please pay attention to multicast... :-)] And, does the
> accounting-model have any impact on the reservation initiation
> direction? 

I found it always a good idea to separate between the initiator of
a reservation request and the actual data senders and receivers.
It should be possible that the initiator is either the sender
or the receiver or maybe also a third party. Looking at DiffServ,
the admission control has usually to start from the sender, because
traffic conditioning elements have to be adapted in a suitable
order. However, there are also ways to have receiver-initiated
reservations for unicast and multicast.

> 5) Routing and reservation "Some have suggested that reservation setup
> necessarily requires route set up, i.e., the imposition of a
> virtual-circuit internet layer.  However, our goal is to simply extend
> the Internet architecture, not replace it.".
>
> I see (once again) some folks at the NSIS list advocating that a route
> set up or VC-like mechanisms is necessary. With our current knowledge,
> is there substansial reasons to change the conclusion of Braden et al?

In my view, routing has to be considered, because the resource management 
must have knowledge of the actual data path. But NSIS should be independent 
of the used routing protocols and allow to use traditional routing
protocols as well as QoS routing protocols etc. However, I see a strong
requirement to have really stable paths which don't change too often.

> (in later chapters)  "It may eventually be possible to fold together
> the routing and reservation setup problems, but we do not yet
> understand enough to do that."
>

QoS routing isn't that easy, but may be available in the future...
so we should not rely on its availability, but see it more as a 
future improvement of resource usage...

> 6) Mobility "The last routing-related issue is provided by mobile
> hosts.  Our conjecture is that mobility is not essentially different
> from other route changes, so that the mechanism suggested ... will
> suffice.  More study and experimentation is needed to prove or
> disprove this conjecture." 

There are differences to route changes, especially during handover,
e.g., resources for a new path may be requested before the actual
route change happens.

> ps,  one issue I deliberately left out was the most obvious:
> "We conclude that there is an inescapable requirement for routers to
> be able to reserve resources, in order to provide special QoS for
> specific user packet streams, or "flows".  This in turn requires
> flow-specific state in the routers,", with Frank Kelly's and others
> work - is this true today, or can we do something much simpler? Or is
> reservations simply a dead end...  

Consider the DiffServ architecture: one needs flow-specific state in 
routers, but not in _every_ router along the path, usually only in first-hop
routers, so this should be manageable. By using aggregation also in the control
plane, we don't need flow-specific states in every element along the (data or
control) path.

> psps I know we have touched on some
> of these issues, but I do not see them as resolved. 

I think that the DiffServ architecture provides answers to most of
the questions.

Regards,
 Roland

-- 
Roland Bless -- e-Mail: [email-masked]
Institute of Telematics, University of Karlsruhe, Germany  
Zirkel 2, D-76128 Karlsruhe -- Office: Bld. 20.20, 3rd floor, R 358
Phone: +49 721 608-6413 Fax: +49 721 388097