Subject: Re: [Ieprep] draft-ietf-ieprep-framework-02.txt

From: [email-masked]
Date: Fri, 1 Nov 2002 13:08:16 EST

In a message dated 10/31/2002 6:52:04 PM Eastern Standard Time, [email-masked] 
writes:

>    > 3.1.  Alternate Path Routing
>     > This objective involves the ability to discover and use a
>     > different path to route IP telephony traffic around congestion
>     > points and thus avoid them. Ideally, the discovery process would
>     > be accomplished in an expedient manner (possibly even a priori to
>     > the need of its existence).  At this level, we make no
>     > requirements as to how the alternate path is accomplished, or
>     > even at which layer it is achieved -- e.g., the network versus
>     > the application layer.  But this kind of capability, at least in
>     > a minimal form, would help contribute to increasing the
>     > probability of call completion of IEPS traffic.
> 
> I cannot begin to express the depth of my disagreement with this
> assertion.  _Nothing short of a backhoe_ will have a more adverse
> effect upon the likelihood of call completion than routing it on a path
> other than that of the production traffic.
> 
> The degree of increased complexity _which has no other purpose_ and
> _would receive no other use_. Emergency systems which share no fate
> with production systems, don't get regular use, and aren't associated
> with any revenue are, without question, doomed to failure.
> 

[MAP] I can't imagine why you are questioning this requirement. It is a 
fundamental requirement of any network to be able to route around congestion 
(and failures).

But, I suspect (presume?) that the Internet already successfully does this, 
so the requirement may not require anything new. But then, once we agree on 
the requirement, we can then decide if anything new is needed.

Mike Pierce
Artel

---

From: Bill Woodcock <[email-masked]>
Date: Fri, 1 Nov 2002 10:20:42 -0800 (PST)

> fundamental requirement of any network to be able to route around congestion

Not at all.  The Internet, for instance, selects the best extant path.
This is _packet switching_, not _channel switching_.  Congestion is an
_instantaneous_ condition on the Internet, it's not a condition which can
be predicted at call-setup time.

    > so the requirement may not require anything new.

You presume wrong.  The Internet consists of individual routers,
each of which works independently to select the best extant path, not a
centralized system which selects a non-optimal uncongested path.

We did it this way because it was an improvement.

                                -Bill

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

---

From: Sean Donelan <[email-masked]>
Date: Fri, 1 Nov 2002 13:29:29 -0500 (EST)

> fundamental requirement of any network to be able to route around congestion

Because its not a fundamental requirement.

Routing around failures is a different requirement from routing around
congestion. In a packet-switched network, "congestion" is not a failure
condition.

In a circuit-switched world, congestion avoidance is a requirement because
circuit-switched networks are inherently blocking along a path.  Circuit
switched networks require alternate path routing during congestion.

On the other hand packet-switch networks are not inherently blocking along
a path under congestion conditions.  You can still send traffic through a
congested path with queue management.  At the first BOF Fred Baker
reported on some testing Cisco did on congested links and what effect it
had on the service delivery.

Both packet-switched and circuit-switch networks need to route around
circuit failures.  Circuit-switched networks use alternate path routing
around congestion. Packet switched networks use queue management during
congestion.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 01 Nov 2002 13:46:45 -0500

While your view certainly represents the "traditional" Internet view and 
current operational practice, one should not forget that there has been 
a large body of more recent research work related to QoS routing. (And 
the good work in that area is well aware of the potential pitfalls that 
lie that way; rehashing the trade-offs here probably serves little 
purpose.) It would probably be wise to at least become aware of that 
work before dismissing things out of hand. The IEPREP documents might 
avoid misunderstandings if they hinted at that general area, so that the 
technically aware reader can file the requirement appropriately.

The IEPREP documents may want to make it clearer as to whether they are 
talking about capabilities that can be supported, with minor local 
additions, using the current operational Internet infrastructure or 
whether they require more fundamental changes. Requirements for QoS 
routing, say, would not be something we can dump in the lap of an 
existing WG, since there is none that I know of. (There is the routing 
IRTF group, but its focus seems to lie elsewhere at the moment.)

It is a separate, charter-level discussion whether IEPREP should 
restrict itself to requirements that can likely be satisfied by work 
that can be accomplished by current chartered IETF WGs.

---

From: Bill Woodcock <[email-masked]>
Date: Fri, 1 Nov 2002 10:50:22 -0800 (PST)

On Fri, 1 Nov 2002, Henning Schulzrinne wrote:
    > a large body of more recent research work related to QoS routing.
    > It would probably be wise to at least become aware of that
    > work before dismissing things out of hand.

Don't be insulting.  Sean is an _operator_.  He's _unfortunately well
acquainted_ with QoS, having _implemented it in the field_ rather than
theorized about it or played with it in the lab.

QoS was an experiment which we've passed well beyond, thank god.  Anyone
still wasting time talking about it is severely disassociated with
reality.  Remember ATM?  QoS was 1999's ATM.  Remember MPLS?  Right, I
think you get my point.

                                -Bill

---

From: Scott Bradner <[email-masked]>
Date: Fri, 1 Nov 2002 13:59:20 -0500 (EST)

> a large body of more recent research work related to QoS routing.

this brings up two questions to me

1/ how close is that research to being deployed in ISPs?

and more importantally

2/ should this WG be talking about what the Internet can be expected
   to be able to do now or in the immediate future (see 1st deliverable
   in the WG charter) of speculate on what might be possible at some
   point in the future?

(my feeling, if its not clear, is that we should stick to the world
of today and the near future)

Scott

---

From: Bill Woodcock <[email-masked]>
Date: Fri, 1 Nov 2002 11:01:21 -0800 (PST)

> 1/ how close is that research to being deployed in ISPs?

We all deployed it, tried very hard to make it work, since people who
purported to be smart kept telling us that it was supposed to make things
better, and then threw it away when we determined empirically that they
were wrong.

    > of today and the near future)

Yep.  Particularly since they're not talking about dependencies on future
practices, but instead upon ones which have already been deprecated and
removed.

                                -Bill

---

From: Sean Donelan <[email-masked]>
Date: Fri, 1 Nov 2002 14:23:18 -0500 (EST)

As long-time readers know, I've been very much in favor of getting
operational experience, identifying the operational problems, and then
solving those problems which have an impact.  I'm not a fan of solving
problems for the sake of solving problems.

I'm don't claim any of the existing systems are perfect.  I don't claim
they will work under every possible condition.  Actually, I expect we'll
find some significant problems in the systems.  I want to find out what
those problems are.  Just getting Bill's INOC-DBA system working, we've
discovered several issues which aren't covered by any of the IEPREP
documents, that need to be addressed in an operational system.

Solutions which require changing how the installed base works may be
technically elegant.  But if a crisis happened this afternoon (or in the
next 10 years), something that worked over the existing Internet would
probably be more useful.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 01 Nov 2002 14:28:03 -0500

At the very least, it would be helpful if drafts clearly separate the 
"here and now" from the "it might be nice to have (topic for future 
research)" and "this is unlikely to be feasible in the Internet as-is". 
The danger with requirements and similar work seems to be that this is 
taken as a license to require things that are extremely unlikely to 
happen in a time frame suitable for IETF output.

Since these documents are also meant for people outside the IETF, 
explicitly identifying things that are unlikely to be feasible 
short-term may be valuable.

(I would be curious what concrete QoS routing has been deployed, tested 
and discarded, given that none was ever really standardized in the IETF, 
as far as I can tell. RFC 2386 seems to be the only output of the QOSR 
working group that concluded in early 1999.)

---

From: Ken Carlberg <[email-masked]>
Date: Fri, 01 Nov 2002 22:33:14 +0000

> additions, using the current operational Internet infrastructure...

yes, can do with respect to making it clearer.

> happen in a time frame suitable for IETF output.

within reason, the Framework document attempts to to this where
appropriate.  the unfortunate aspect was the use of the word 
"requirement" in the document.  as stated earlier, different
phrasing will be used to avoid this confusion.

> short-term may be valuable.

agreed.  in addition, more background than normally used is meant to 
educate both the traditional IETF'ers and those of other backgrounds

-ken

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 4 Nov 2002 17:07:48 -0500

On Friday, Nov 1, 2002, at 14:28 America/Montreal, Henning Schulzrinne 
wrote:
> (I would be curious what concrete QoS routing has been deployed, 
> tested and discarded, given that none was ever really standardized in 
> the IETF, as far as I can tell. RFC 2386 seems to be the only output 
> of the QOSR working group that concluded in early 1999.)

OSPFv2 in Proteon's implementation (and a couple others, probably 
including
ACC's implementation) supported QoS routing using the IP ToS bits 
(RFC-791
definitions, not DiffServ definitions).  The DELAY bit actually worked 
quite
well trans-Pacific for selecting copper cable vs SATCOM hop in my own 
experience.

The precedence bits worked as designed -- though the design for them 
explicitly
meant that FLASH was intended to starve lower precedence values 
whenever necessary
to make sure the FLASH packets really got through.  This design might 
have
limited applicability in a commercial network than it did in the DDN.

It would be interesting to hear from Sean/Woody about which particular 
QoS
mechanisms they were referring to, but it isn't clear to me how much 
that
would be on topic here...

To Scott's point, I am not aware of any large-scale production IP 
network
today with any deployed QoS -- this includes the DISA IP networks (which
do not have deployed QoS and will not unless JCS grants explicit 
permission
to DISA in advance; I wouldn't hold my breath waiting for that either).

Ran