Re: Last Call for draft-ietf-rolc-apr-00.txt

[Curtis Villamizar <[e-mail]>]

Yakov,

Some of this is in the reply to your reply to specific comments.  I've
sent some of the comments to the list so that others might consider
them.  We are clearly converging on constructive dialog and progress.

In message <[e-mail]>om>, Yakov Rekhter writes:
> 
> The major point made in the document is that the choice between "local"
> and "remote" decision should be totally decoupled from the addresses of
> src and destination.

Your draft may be a good addition to RFC1821, with significant
modification though.  I've heard rumblings that not everyone supports
that RFC.  If there are objections to it, those someones should speak
up.  RFC1821 speaks to the issues of QoS.  It brings up issues but
neither tries to dismiss any or declare them insurmountable.  It also
address the local/remote decision in section 4.3.  Perhaps this
treatment is too brief:

 4.3 Mapping IP flows to ATM connections

   In general, there will be a great deal of flexibility in how one maps
   flows at the IP level to connections at the ATM level. For example,
   one could imagine setting up an ATM connection when a reservation
   message arrives at the edge of an ATM cloud and then tearing it down
   as soon as the reservation times out. However, to minimize latency or
   perhaps for economic reasons, it may be preferable to keep the ATM
   connection up for some period in case it is needed. Similarly, it may
   be possible or desirable to map multiple IP flows to a single ATM
   connection or vice versa.

   An interesting situation arises when a reservation request is
   received for an existing route across the cloud but which, when added
   to the existing reservations using that connection, would exceed the
   capacity of that connection. Since the current  ATM standards do not
   allow the QoS of a connection to be changed, there are two options:
   tear down the old connection and create a new one with the new,
   larger allocation of resources, or simply add a new connection to
   accommodate the extra traffic. It is possible that the former would
   lead to more efficient resource utilization. However, one would not
   wish to tear down the first connection before the second was
   admitted, and the second might fail admission control because of the
   resources allocated to the first. The difficulties of this situation
   seem to argue for evolution of ATM standards to support QoS
   modification on an existing connection.

If all you need to do is describe the flexibility in making the
local/remote decision in greater detail, perhaps you should write a
draft that does just that.  I see three (binary) parameters:

	default traffic treatment vs special traffic class
	shared traffic treatment vs individual flow traffic treatment
	hop-by-hop vs cut-through (aka local/remote)

Various combinations may provide better QoS or more efficient delivery
of service.  One combinations may work best for some traffic
characteristics and traffic requirements and another combination may
work best for other types of traffic.  The draft would be greatly
improved by acknowleging that QoS is can also be provided using
hop-by-hop and shared special traffic class traffic treatment or
individual flow traffic treatment in addition to cut-through and
various traffic treatments.

Hop by hop QoS may exist and cut through may exist.  Both can be
considered where available.  Some people may think one or the other
won't be available.  Some may prefer not to consider one or the other
for some reason, perhaps a scaling, performance, implementation
quality, or other practical reason that we cannot forsee at this
point.  We should not try to prejudice the technolgy selection in a
draft that tries to define the playing field.

> I have no problems of describing the decoupling the "local/remote"
> outcome from the addressing information as "an extension" (or probably
> "evolution").

IMO Declaring a "new IP architecture" is generally a bad thing to do
unless that is closer to what you are doing.  This is a minor
extension.

Something like IPv6 might qualify as an architecture change, though
even then a major change, but minor architecutre change since IP is
still connectionless with the same connection oriented end-to-end
transport on top, though major changes were made to packet formats,
address resolution procedures, support for security and other areas.

> Yakov.

Another key point (from the off list exchange):

A new term was needed for "a specific subset of the internetwork
topology in which the underlying network does not prevent all hosts or
routers from being directly reachable without IP forwarding to an
intermediate party".  This has nothing to do with addressing and any
overlap with an address prefix, whether intentional or coincidental,
does not define the region.  The term "address prefix region" is
absolutely the wrong term.  The old terms commonly used were "NBMA
network" or "subnet in the OSI sense".  You need to pick a term that
clearly reflects what you are describing.

You are proposing to decouple addressing and then defining a term that
couples "aka NBMA network" with an address prefix.  Fix the ommision
of hop-by-hop QoS and one hop off the NBMA procedures and get rid of
the coupling with address prefix entirely and I'll wholeheartedly
support the draft.

Sorry to be so critical on the list but this was issued as a last
call, which I think was totally inappropriate.  We seem to be very
rapidly coming to agreement off list.  IMO a first draft should never
have been issues as a last call so the document can be refined
gradually (and more calmly) and then issued for last call when comment
subside.  I personally appologize for being overly harsh.

Curtis

PS - This was a misstatement on my part: "... and a good deal of
misinformation about the state of IP and QoS is presented".  On
rereading I could see there was no factual error.  The document was at
worst only misleading in its ommision of consideration of the support
of QoS using hop-by-hop forwarding and appropriate traffic treatment.