Subject: RE: [NSIS] Looking back at RFC 1633

From: "Chen, Weijing" <[email-masked]>
Date: Fri, 5 Apr 2002 08:34:47 -0600

Well said. We are so quick to discard previous work since it is not our
invention, and so eager to re-invent the wheel since it will have our name
on it.

A sadden state of current technology industries, we may know more about
technology, but we lost fundamental engineering and scientific discipline.

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, April 05, 2002 2:56 AM
To: [email-masked]
Subject: [NSIS] Looking back at RFC 1633

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

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