Subject: [Ieprep] New Internet Drafts

From: [email-masked]
Date: Wed, 30 Oct 2002 17:22:32 EST

To all,

I have submitted the following 3 drafts:

Requirements for Assured Service Capabilities in Voice over IP
Architecture for Assured Service Capabilities in Voice over IP
Examples for Provision of Preferential Treatment in Voice over IP

These are revisions of previous drafts submitted to SIPPING. Since their 
initial submission, the discussion related to the subjects rasied in these 
drafts has moved to IEPREP.

While these mostly deal with "Assured Service", or the intended service to 
replace "MLPP" in the military network, I believe that many of the concepts 
discussed are common with "Authorized Emergency" calls which IEPREP has been 
focusing on. In fact, "MLPP" in a military network is simply another form of 
"authorized emergency" priority calls.

Please note that these drafts are jointly authored by myself (of "Artel") and 
Don Choi, of DISA, the agency responsible for establishment of standards and 
policies for the US Defense Network.

These drafts can be found at:

<A HREF="http://www.ietf.org/internet-drafts/draft-ietf-ieprep-requirements-01.txt">http://www.ietf.org/internet-drafts/draft-pierce-ieprep-assured-service-req-00

.txt</A>
<A HREF="http://www.ietf.org/internet-drafts/draft-ietf-ieprep-requirements-01.txt">http://www.ietf.org/internet-drafts/draft-pierce-ieprep-assured-service-arch-0

0.txt
</A><A HREF="http://www.ietf.org/internet-drafts/draft-ietf-ieprep-requirements-01.txt">http://www.ietf.org/internet-drafts/draft-pierce-ieprep-pref-treat-examples-00

.txt</A>

Mike Pierce
Artel

---

From: Bill Woodcock <[email-masked]>
Date: Wed, 30 Oct 2002 16:28:33 -0800 (PST)

> This document outlines user requirements...

This does not in fact appear to be the case.  In fact, this appears to
outline government expectations of service providers and vendors.

The market mechanism for fulfillment of government expectations is for
the government to purchase what it wants within the market.

Not to impersonate the user community.

I'd humbly suggest that since the expectations being outlined in this
document are extrordinarily expensive ones, it might benefit the
expectant party to moderate its expectations somewhat, or suggest how
much it's interested in paying, and allow the market to present
offerings which meet that price range.

Stating overblown expectations in a financial vacuum is feckless.

    > There are four basic configurations that come
    > into play during convergence.  These include:
    > o  Pure IP telephony, with no link to the PSTN

This appears to be largely ignored in the rest of the document. Out in
the real world, however, it appears to be a significant portion of the
total, however.

    > We assume the presence of Service Level Agreements

Which are a marketing, sales, and collections fiction.  If you want to
base a standard on a sales practice, the IETF isn't an appropriate
place to do it.

    > sessions should be provided with with a higher probability of
    > completion over non-emergency communications.  We assume the
    > presence of a service level agreement to accomplish this.

Sales fictions do not accomplish operational objectives.  However, one
might view QoS as an operational instantiation of SLAs, and it's
instructive to note that QoS is substantially more fictional than SLAs.
Since it doesn't work and wouldn't provide any desired utility even if
it did, it's neither used nor desired on any significant networks. Much
less on significant production VoIP networks.

    > Emergency traffic should be able to transit multiple service
    > providers.  The existence of service level agreements determines
    > the extent by which this can be accomplished.

Could have fooled me.  I thought network interconnection determined the
extent to which traffic could be exchanged. Silly me.  I'll go sign a
bunch of SLAs.  That's got to be easier than actually building a network.

    > Networks should be able to support a variety of user applications
    > including telephony, video, database access, messaging,
    > telemetry, and web browsing to support emergency operations.

Uh, am I really reading this in an IETF document?  Hello?  Networks
SHOULD make toast?

    > Users should have the option protecting certain sensitive traffic
    > from eavesdropping and the source/destination of some traffic.

"Users" REQUIRE that service providers SHOULD give users the option of
putting a big pillowcase over their heads before answering the phone?
Or shutting their office door before answering the phone?

    > Users should have the option of requesting degraded quality of
    > service when normal or expected QoS cannot be achieved.

This one is really cute.  Brings to mind the Star Trek movie in which
Scotty travels back in time and operates a Mac Plus.

Users are more than welcome to request degraded quality of service at
any time.  Please speak loudly into the mouse, before dialing.

So,in summary, what we appear to have here is a document which:

- pretends to document "user requirements" while not actually
  representing users;

- asks for hugely expensive "features" without suggesting who, or even
  whether, anyone would be willing to pay for them;

- and is based upon the assumption an idiotic sales practice being
  ubiquitous.

Why are we discussing this, again?

                                -Bill

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

---

From: Bill Woodcock <[email-masked]>
Date: Wed, 30 Oct 2002 16:53:20 -0800 (PST)

> putting a big pillowcase over their heads before answering the phone?

Sorry, read that as "eavesdropping AT the source/destination".  So I'll
change my critique to simply pointing out that this is why IPSec exists,
so the obvious doesn't need to be reiterated in this document.

                                -Bill

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 30 Oct 2002 20:02:38 -0500

On Wednesday, Oct 30, 2002, at 17:22 America/Montreal, [email-masked] 
wrote:
> Please note that these drafts are jointly authored by myself (of 
> "Artel") and Don Choi, of DISA, the agency responsible for 
> establishment of standards and policies for the US Defense Network.

	I'd be very interested to see the folks who actually run the DISN [1]
comment here about the deployability of this proposal inside their 
current
operational IP networks.  I'm reliably told DISA aren't using DiffServ 
today
in their production IP WANs.

	For that matter, I'd be interested in feedback from anyone here with
hands-on operational experience with a large-scale DiffServ deployment
in a production (i.e. not research) IP network.  Right now, I'm not 
familiar
with any large-scale deployment of DiffServ in a production IP network,
though I know of several small deployments or research projects that 
have
used DiffServ in one way or another.  Lack of operational experience 
with
any technology being required in widescale deployment always makes me 
nervous.[3]

Regards,

Ran
[email-masked]

[1] DISN is their jargon for the part of DISA that runs their IP 
networks.
At DISA, the folks who work on policy/standards are largely separate 
from
the folks who actually engineer/operate the {N,S}IPRnet and the other 
more
highly classified IP networks.

[2] Disclaimer:  My employer IP makes routers that implement DiffServ.  
While
this doesn't affect my views, full disclosure is always best in these 
situations.

[3] This is why I also dislike most proposed "enhancements" to (M)BGP4, 
to give
an unrelated example.

---

From: "Steve Silverman" <[email-masked]>
Date: Wed, 30 Oct 2002 21:37:01 -0500

> Not to impersonate the user community.

If an organization employs the person holding the phone and pays the bills
for that person,
I believe we typically call that a user organization.

> Stating overblown expectations in a financial vacuum is feckless.

The user requirements that have been stated are functions that have been
used and available
for over forty years.   Rumor has it, that VoIP can provide these same
functions for less money.  That's why many people are working on this.  If
the technology can't match these functions, then we have to decide if we
want it.  But for the moment, we're trying to build a usable system for our
requirements.

> Or shutting their office door before answering the phone?

There other more effective ways of doing this.

> - pretends to document "user requirements" while not actually

We do represent real users.

>   whether, anyone would be willing to pay for them;

The DOD has been supplying and paying for these services for decades.

Steve Silverman
Houston Associates
working for the US Air Force

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 30 Oct 2002 22:54:13 -0500

On Wednesday, Oct 30, 2002, at 21:37 America/Montreal, Steve Silverman 
wrote:
> used and available for over forty years.

...in the PSTN, using entirely different underlying technology...

> Rumor has it, that VoIP can provide these same functions for less 
> money.

That phrasing is hard to argue with, since it acknowledges so much 
uncertainty.

Personally, I think it is FAR from clear that VoIP (at any price) will 
provide
identical capabilities as the PSTN -- because the underlying 
communications
technologies have VERY different architectures, design objectives, and 
implementations.

I will also note that other "users" (e.g. Japan) have no stated interest
in VoIP as an IEprep service -- and are instead focused on how to use
IEprep services to provide enhanced performance for traditional Internet
applications (e.g. web, email).  In short, there are a variety of users,
with different desired features/applications/desires.

I think a more productive approach would be for discussion here to 
focus on services
that a typical current commercial deployment of standards-based 
Internet network
technology might be able to provide, as compared with trying to put the
PSTN-capabilities ("a square peg") into the existing Internet ("a round 
hole").
(Square pegs are fine if one has a square hole, but they don't fit well 
in any
size of round hole. :-)

Ran
[email-masked]

---

From: Ken Carlberg <[email-masked]>
Date: Thu, 31 Oct 2002 09:33:28 +0000

It would be more constructive if you could provide technical points
of discussion and a more precise set of comments.  Responses to very
general comments/opinions and sarcasm tends to be a bit fruitless in
the end.

If you wish to stand by your comments as they exist, then perhaps its
better to end this particular thread.

> Why are we discussing this, again?

at the Yokohama meeting, there was basically no contentious arguements
expressed about the version -00 draft (nor has there been any on the
list that i recall since yokohama).  There did seem to be some hallway
discussions (one of which I participated in), but a hallway discussion
is private and not an open debate and so others not participating cannot
be expected to respond to them.

the version -01 draft is the result of one such discussion that did 
make it back to the authors, and as a result, the -01 draft is more
constrained, smaller (sections taken out), and has sections that have
been reworded to focus on words like "must" and "should".  

my personal desire would be to hold off final debate on the -01 draft
until the carlberg/atkinson requirements drafts have been advanced.
but, thats not my call to make.

regards,

-ken

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 31 Oct 2002 10:18:48 -0500

Ken indicates he didn't follow all of Bill's comments.

I'll try to restate a few of them -- no doubt Bill will correct
any errors I make.  Note that I'm just trying to translate Bill's
comments, neither agreeing nor disagreeing with them necessarily.
I'll make my own comments within a few days.

On Wednesday, Oct 30, 2002, at 19:28 America/Montreal, Bill Woodcock 
> Stating overblown expectations in a financial vacuum is feckless.

Bill differentiates between government expectations and non-government
user requirements and suggests the document is mis-titled and maybe
poorly described in its introduction.

> the real world, however, it appears to be a significant portion of the

	Bill runs one of the larger pure VoIP services deployed today,
which might not be widely known outside the IP Carrier community.

	That service has *no* current or future interconnection with the PSTN.
He is observing that the largest VoIP deployments today generally
do *not* have any current or planned interconnection with the PSTN.
He notes that the document seems unaware of the nature of current
large-scale inter-domain VoIP deployments.

> base a standard on a sales practice, the IETF isn't an appropriate

He's saying the assumption is not well founded.

> less on significant production VoIP networks.

He's noting that most (all that I'm familiar with, actually) current
SLAs are written by the IP Carrier with sufficient care that the SLAs
are unenforcable, both in practice and in law.  Many current IP Carriers
outright refuse to offer SLAs today.

He also notes that current large-scale production VoIP services, such
as his, don't use or need SLAs for proper operation.  I'll also note
that Bill's VoIP service is intended for primary use when the global
Internet is under a lot of stress, so he does care about service
availability.

> bunch of SLAs.  That's got to be easier than actually building a 

Bill is observing that ability to transit in fact relies almost 
exclusively
on the BGP protocol, what is advertised there, and what BGP puts into
forwarding tables in deployed routers.  Such forwarding is a technical
function that is oblivious to the presence/absence of any SLA.

> Uh, am I really reading this in an IETF document?  Hello?  Networks

Not sure what Bill means here.

> Or shutting their office door before answering the phone?

Bill's wording is sub-optimal, but I think his point is that if any
end-user wants security, then that end-user should be using end-to-end
security mechanisms deployed by the user.  TLS, ESP, and AH would be
examples of such services that are normally deployed by the end-user
-- not by the IP carrier.

> any time.  Please speak loudly into the mouse, before dialing.

Bill's point seems to be (I'm not entirely sure) that the real deployed
Internet has no concept of QoS -- not merely no concept of "good" QoS
but no concept of "QoS" at all.[1]  For example, there are no large 
scale
DiffServ or RSVP deployments in commercial IP networks today as near
as I can tell.  Perhaps equally relevant is that IP Carriers have 
roughly
nil capital budget to buy new routers these days, while most deployed 
routers
can't support QoS without suffering degraded packet forwarding rates.[2]

Regards,

Ran
[email-masked]

[1] Caveat:	Most deployed backbone/core routers do differentiate packets
	that are marked with the "Internet Control" IP ToS bit pattern as
	defined in RFC-791 -- and give those packets lower drop preference.  
This
	is done to try to ensure that BGP traffic, essential for maintaining
	accurate routing/forwarding tables, is unlikely to be dropped should
	stress occur on some link.  The mechanism is not necessarily part of
	a broader implementation of IP ToS/DiffServ support.
[2] Exceptions exist, but it seems inappropriate to mention specific 
vendor
	names on this mailing list.  People who are really interested in this
	can send me private email for my personal (not corporate) opinions
	on this.  I never speak for my employer.

---

From: Sean Donelan <[email-masked]>
Date: Thu, 31 Oct 2002 11:07:52 -0500 (EST)

> 	a broader implementation of IP ToS/DiffServ support.

While the internals of particular implementations likely vary, as I
understand it, a backbone/core router differentiate packets originated
by itself.  The IP ToS bits are set for bookeeeping purposes. The real
method how BGP or link-level Keepalives get to the front of the queue
is because when the router originates the packets, it puts some of its
own packets at the front of the queue.

Packets originating on other routers with the IP ToS bits are not handled
differently, even if those protocols would have been prioritized on the
same router. Multi-hop BGP packets do not receive special handling by
other routers.  Since anyone can run any protocol on any port, if
backbone/core routers did prioritize port 179 packets; what would happen
is people would run Quake/Doom servers on port 179.

As you say, the link-level prioritization done by routers is not
necessarily part of a broader implementation of IP ToS/DiffServ support.

---

From: Ken Carlberg <[email-masked]>
Date: Thu, 31 Oct 2002 16:29:28 +0000

proxy discussion.  cool :-)

> poorly described in its introduction.

ok, this is a critic one can address and respond to.  who is considered a 
can be clarified and expanded upon.

> large-scale inter-domain VoIP deployments.

understood.  the purpose of the passage about "4 basic configurations"
was to acknowledge that more than one exists and that users of an
authorized emergency service should keep this in mind.  what one 
cannot determine from Bill's original statement is *how* that one
scenario he points out (and obviously relates to) is ignored.  Is
there a requirement missing, or is something else amiss? -- I'd don't
know and prefer not to guess.

> He's saying the assumption is not well founded.

we have used the term "business agreement" instead of SLAs in our
other documents.  the intent is to convey the expectation of a
charging in some form of a contracted service that is outside of
best effort or normal service.  if the term "SLA" has too much 
baggage or negative association attached to it, a different term 
can be used.

> outright refuse to offer SLAs today.

and some do.  as you know, I've seen and experienced some whoppers

> Internet is under a lot of stress, so he does care about service

understood.

> function that is oblivious to the presence/absence of any SLA.

understood.  but this seems to reflect a disconnect and probably a need
for additional clarification in the -01 document.  The original passage
probably should have stated "labeled emergency traffic".  The traffic
itself could be diff-serv marked IP packets (and before you say "don't
expect to use diff-serv" :-), I'll save you the trouble and agree that 
for now, diff-serv is a VERY rare offering).  Or they could be labeled
application layer packets.  In either case, the user would have the 
expectation that the labeled traffic transits other providers as opposed
to be dropped because it is unrecognized.  Further, that this expectation
can only exist if "business contracts" have been set up with those that
would examine the label.  if the business contract doesn't exist, or the
labels isn't examined, then expect normal (presumably best effort)
service.

but again, it would seem that the original passage needs clarifications.
that can be done.

> -- not by the IP carrier.

right, your wording is understood.  I think the original passage was
meant to touch upon anonymity, but thats conjecture on my part.

> can't support QoS without suffering degraded packet forwarding rates.[2]

ok.  your interpretation would again seem to foster a need for more
clarification on the authors part.  the intent of the original passage
was aimed at the QoS experienced by the end-user and not necessarily
that offered by the network.  for example, using lower quality/bandwidth
codecs, or adding FEC -- ie, something other than standard end-to-end
service.

cheers,

-ken

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 31 Oct 2002 11:37:46 -0500

On Thursday, Oct 31, 2002, at 11:07 America/Montreal, Sean Donelan 
wrote:
> by itself.

For the systems I'm familiar with, the internal implementations do vary,
but the concept of operations and intended results are very similar.

> The IP ToS bits are set for bookeeeping purposes.

Maybe.  In at least 2 widely deployed implementations, the IP ToS bits
are (were ?) set on outgoing BGP packets in order to provide clues to 
other
deployed routers along the path used by the BGP packets.  I haven't run
this experiment recently, but it was certainly true ~3 years ago.  The
behaviour of shipping code might have changed during that time.

> The real method how BGP or link-level Keepalives get to the front of 
> the queue

This is true, but incomplete.  In at least 2 widely deployed 
implementations,
the code inside ip_input() looks for packets with the magic IP ToS value
set and then verifies that they are BGP packets (by looking at 
protocol=TCP
and port=BGP) and handles them with reduced drop preference.  The degree
of reduced drop preference is unclear to me (and is somewhat debatable) 
absent
some scientific testing, but notionally it is present.

> other routers.

The above is not the case for at least 2 widely deployed 
implementations.

> Since anyone can run any protocol on any port, if

It certainly is a potential threat.  Many ISPs configure their access 
routers to strip
the IP ToS bits on all packets received from customers -- in order to 
mitigate
such threats.  This last practice is a de facto barrier to widespread 
DiffServ
deployment.

> necessarily part of a broader implementation of IP ToS/DiffServ 

Glad we agree on that.

Ran
[email-masked]

---

From: Bill Woodcock <[email-masked]>
Date: Thu, 31 Oct 2002 09:24:17 -0800 (PST)

On Thu, 31 Oct 2002, Ken Carlberg wrote:
    > of discussion.

Peter and I tried that at the last meeting, and nobody wanted to talk
about technology.  Instead, we get this document, which consists largely
of statements of the form "The PSTN makes toast!" and "We _like_ toast!"
and "The Internet SHOULD make toast!" and "Salespeople SHOULD tell us that
the Internet makes toast!"

    > expressed about the version -00 draft

Very generous of you to characterize Peter and myself as uncontentious.
Or perhaps you're just forgetting that you ignored everything we said.

I would really welcome _any little tidbit of technical anything_ that
could be debated.  As it is, the document is just a bunch of
long-winded platitudes about the PSTN and about sales practices.  Not much
for an engineer to debate.

                                -Bill

---

From: Bill Woodcock <[email-masked]>
Date: Thu, 31 Oct 2002 09:56:07 -0800 (PST)

> the purpose of the passage about "4 basic configurations"
    > scenario he points out (and obviously relates to) is ignored.

This was what I was principally objecting to at the Yokohama meeting:
there seems to be an underlying assumption that the PSTN will connect to
arbitrary other voice networks.  My own network appears to be the
exception in that PSTN operators do in fact seem to be eager to connect to
it and bear the costs of doing so, but in the general case, they don't
seem to be interested in doing so.

If the document or the expectant party which it represents wants to be
able to pick up an arbitrary telephone and call an arbitrary other
telephone, this presupposes interconnection between the two networks which
serve the respective telephones.

I would point out that the expectant party has historically been one of
the main consumers of disconnected telephone networks, and was in fact
proposing to create yet another just this week at NANOG.  So this is
clearly not a useful expectation.

    > > > Which are a marketing, sales, and collections fiction.
    > other documents.

Right.  So isn't this CLEARLY OUTSIDE THE REALM OF THE IETF?  Since when
does the IETF standardize business agreements?

    >>>> providers.
    > The original passage probably should have stated "labeled emergency
    > traffic".  The traffic  itself could be diff-serv marked IP packets.
    > Or they could be labeled application layer packets.  In either case,
    > the user would have the expectation that the labeled traffic
    > transits other providers as opposed to be dropped because it is
    > unrecognized.

Then the user's expectation would be unfulfilled.

You're completely missing the point.  _No_ traffic is going to transit
multiple service providers unless the service providers are
interconnected.  Interconnection is a physical process, not a sales
process.

    > Further, that this expectation can only exist if "business
    > contracts" have been set up... if the business contract doesn't
    > exist... then expect normal (presumably best effort) service.

No, no, no.  If the _physical interconnection_ doesn't exist, then expect
_no_ service.  Has nothing to do with business contracts.

    >> Bill's point seems to be that the real deployed Internet has no
    >> concept of QoS -- not merely no concept of "good" QoS but no
    >> concept of "QoS" at all.

Correct.  We all tried, multiple times, but since it made everything
worse, rather than better, and cost money rather than saving money, it
died a well-deserved death quite a few years ago.

End users are perfectly welcome to assume its existence and "request
degraded service" all they like.  They can also wave magic wands and chant
incantations.  We'll keep routing packets either way.

    > the intent of the original passage

Then it doesn't belong in the document, does it?  Users are welcome to do
whatever users do.  That doesn't constitute an expectation of service
providers.

                                -Bill

---

From: Bill Woodcock <[email-masked]>
Date: Thu, 31 Oct 2002 10:05:19 -0800 (PST)

On Wed, 30 Oct 2002, Steve Silverman wrote:
    > > This does not in fact appear to be the case.
    > If an organization employs the person holding the phone and pays
    > the bills for that person, I believe we typically call that a user
    > organization.

I suggest you familiarize yourself with the operation of the IETF before
attempting to participate.

Organizations are not entitled to representation in the IETF.  Individuals
represent themselves in the IETF.

    > The user requirements that have been stated are functions that have
    > been used and available for over forty years.

That's nice.  Take it to the ITU.  We engineer Internet protocols here.

    > We do represent real users.

That's interesting.  I look in my phonebook, and I see an "Atkinson" and a
"Lothberg" and a "Bradner", but no "Silverman", and no "Force, U.S. Air".

                                -Bill

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 31 Oct 2002 13:39:02 -0500

On Thursday, Oct 31, 2002, at 12:56 America/Montreal, Bill Woodcock 
> whatever users do.  That doesn't constitute an expectation of service

Two comments:

1) I'll push back a bit on Bill about the above.

	It seems to me that it is OK (and there is precedent) for folks to 
write
non-standards-track documents about topics which are beyond pure 
protocol
specs and publish those as Informational RFCs.  It is true that 
standards-track
IETF documents are nearly always protocol specs (the exceptions seem to 
be
a handful of BCPs trying to dispense free clues or discussing IETF 
processes),
but the proposal on the table is for Hal's document to go out as 
Informational,
not standards-track.  It is important (and the IESG traditionally will 
insist)
that non-standards-track documents use language that makes it clear 
that the
document is non-standards-track.  I'm not sure which precise criteria 
the IESG
use for making that determination during their pre-publication review.

2) I could be wrong, but it seems that one of Bill's concerns is that 
Hal's
document is written editorially so that it can be (mis)read as speaking 
for
"all users" when it is more accurately the perspective of "some users" 
or
"one user" (being DISA/NCS).  Re-titling the document or editing the 
introduction
to make it clear that the document provides one user's perspective on 
IEprep
services (and that other perspectives could hypothetically exist) would
likely help.  Dropping the word "requirements" would also help, since 
the IETF
usage of "requirements" is pretty narrow and normally means that either 
an
implementer has to do a specific thing or an operator (like Bill) has 
to do
a specific thing.  That word might be causing unintended confusion here.

(Bill might dispute 1 and correct me on 2, but dialogue helps at least 
for now :-)

Regards,

Ran
[email-masked]

PS:		It would be nice if Bill would also examine and comment on the two
	I-Ds from Ken Carlberg (draft-carlberg-ets-*).  Those are *intended* to
	eventually become standards-track (BCP or PS, not sure what the IESG 
wants),
	so would also benefit from wider review, particularly from operators 
and
	implementers.

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 31 Oct 2002 13:42:13 -0500

On Thursday, Oct 31, 2002, at 13:05 America/Montreal, Bill Woodcock 
> "Lothberg" and a "Bradner", but no "Silverman", and no "Force, U.S. 

(Attempting translation again)
	The document was not written by one of Bill's VoIP users.  And he 
probably
does not intend to offer IEprep capabilities (or even universal 
interconnection
with other VoIP or PSTN services) with his VoIP service.

	Maybe this means that it would help if the draft were edited to narrow
the scope to "commercial VoIP services which are fully interconnected 
with the PSTN
and choose to offer IEprep support" (edit to taste) ?

Ran

---

From: Bill Woodcock <[email-masked]>
Date: Thu, 31 Oct 2002 10:51:45 -0800 (PST)

> the proposal on the table is for Hal's document to go out as
    > Informational, not standards-track.  It is important (and the IESG
    > traditionally will insist) that non-standards-track documents use
    > language that makes it clear that the document is non-standards-track.

And not best-practices.

So it's documenting one user's experience with the PSTN, and the fact that
that one user would prefer it if the Internet operated more like the PSTN,
and less like the Internet.

    > Hal's document is written editorially so that it can be (mis)read as
    > speaking for "all users" when it is more accurately the perspective
    > of...  "one user" (being DISA/NCS).

Correct.

    > Re-titling the document or editing the introduction to make it clear
    > that the document provides one user's perspective on IEprep
    > the IETF  usage of "requirements" is pretty narrow and normally
    > means that either an implementer has to do a specific thing or an
    > operator (like Bill) has to do a specific thing.

Correct.

                                -Bill

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 31 Oct 2002 13:06:35 -0600

The IEPREP Charter (paragraph #1):

"Effective telecommunications capabilities are imperative to facilitate
immediate recovery operations for serious disaster events, such as,
hurricanes, floods,
earthquakes, and terrorist attacks. Disasters can happen any time, any
place, unexpectedly. Quick response for recovery operations requires
immediate access
to any public telecommunications capabilities at hand. These capabilities
include: conventional telephone, cellular phones, and Internet access via
online
terminals, IP telephones, and wireless PDAs. The commercial
telecommunications infrastructure is rapidly evolving to Internet-based
technology. Therefore,
the Internet community needs to consider how it can best support emergency
management and recovery operations. 

Three examples of emergency communications include: 

1. Conveying information about the priority of specific phone calls that
originate in a VoIP environment through gateways to the PSTN. "

Bill - this charter seems to describe networks *other* than yours (because
of your choice of interconnectivity issues); therefore I believe your
discussion is out of scope for this list until *you* can change the charter
to *not* state IEPREP directly involves the commercial telecommunications
industry (which means at least also interconnectivity to the PSTN/GSTN/CSN).

I have my own issues with the ID, but clearly don't want to hear your
ranting BS that doesn't apply to the charter (which the Reqs ID here
attempts to do).

BTW - this seems like a very good time for *you* to write an ID about the
issues and requirements involving Topology "End-to-End IP" from:
http://www.ietf.org/internet-drafts/draft-polk-ieprep-scenarios-01.txt
THE purpose for that ID is to bring overlapping and unique discussions
regarding the similarities and differences surrounding each of the 4 basic
Topologies. I have read through ~10 emails that you (and maybe Ran) want
your Topology to be overlapping in nature (therefore everything changed)
with respect to the other 3 Topologies - yet your unclear reasoning seems
to point to your uniqueness relative to the other Topologies. 

One problem I see with you doing this is your intent on *not* connecting to
IEPREP/ETS/GETS/GTPS services of any kind (so why are you commenting at all
to this discussion that will not involve you or your network?). 

Send text or write your own ID -- you seem to feel quite strongly about this.

nuff said (in your equally brash manner)!

>whatever users do.  That doesn't constitute an expectation of service

cheers,
James 

              *************************************
"People generally demand more respect for their own rights than 
                         they are willing to allow for others"

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 31 Oct 2002 15:32:32 -0500

On Thursday, Oct 31, 2002, at 14:06 America/Montreal, James M. Polk 
> industry (which means at least also interconnectivity to the 

No, Bill's comments aren't out of scope due to charter.  Instead, the 
draft
needs to be edited to specifically fit within the scope of this WG's 
charter
and ensure that any reader of the draft is not confused about the 
intended
scope of the draft.

> to this discussion that will not involve you or your network?).

A good reason is that the draft under discussion appears to claim to 
apply
to all networks -- not just those that choose to sell IEprep services.  
This
is easily fixable by editing the draft under discussion -- and that is 
the
right kind of fix to undertake.

Regards,

Ran
[email-masked]

---

From: Bill Woodcock <[email-masked]>
Date: Thu, 31 Oct 2002 13:06:59 -0800 (PST)

On Thu, 31 Oct 2002, James M. Polk wrote:
    > ...public telecommunications capabilities at hand. These
    > capabilities include: conventional telephone, cellular phones, and
    > Internet access via online terminals, IP telephones....

Right.  So Peter and I both operate global Internet networks over which
global voice networks consisting of IP telephones operate.

    > Therefore, the Internet community needs to consider how it can best
    > support emergency management and recovery operations.

...and the principal purpose of the voice network that I operate is
Internet infrastructure protection, emergency response, and operational
change coordination.

    > this charter seems to describe networks *other* than yours;
    > therefore I believe your discussion is out of scope for this list

Hm.  Not quite sure how you come to this conclusion.

    > IEPREP directly involves the commercial telecommunications

Uh, I thought it explicitly included VoIP networks which _weren't_
interconnected with the PSTN.  I think you guys need to make up your minds
whether you're trying to require something of me or not.

    > this seems like a very good time for *you* to write an ID about the

Uh, I typically only take time away from operational work to respond to
requests for my "ranting BS" from the IESG/IAB level.

    > I have read through ~10 emails that you (and maybe Ran) want
    > with respect to the other 3 Topologies

Please clarify this?  My objection is to someone suggesting that they're
requiring something of me (QoS or interconnection with arbitrary other
networks being two examples) which I may either be unable to complete
autonomously, which they may be unwilling to pay for, or which I may have
neither engineering nor business motivation to do.

    > to this discussion that will not involve you or your network?).

Are they services, networks, or requirements?  I can only "connect" my
network with another network, not a "service" or a "requirement."  If it
won't involve me or my network, why is it called a "requirement?"

                                -Bill

---

From: Sean Donelan <[email-masked]>
Date: Thu, 31 Oct 2002 16:31:58 -0500 (EST)

On Thu, 31 Oct 2002, RJ Atkinson wrote:
> implementations, the code inside ip_input() looks for packets with the
> magic IP ToS value set and then verifies that they are BGP packets (by
> looking at protocol=TCP and port=BGP) and handles them with reduced
> drop preference.  The degree of reduced drop preference is unclear to
> me (and is somewhat debatable) absent some scientific testing, but
> notionally it is present.

I'll admit I have not tried it recently.  Proteon routers were very much
ToS aware, and ToS bits could make a significant difference.  But most of
the other brand routers I tried, ToS seemed to be a no-op, except for
locally originated packets.  I haven't seen the router source code, so I
don't know their precise handling of the ToS bits.  Treating the router as
a black-box, our testing didn't show any difference between packets with
ToS bits and packets without ToS bits.  But I didn't try every combination
of packet, protocol, port, ToS, etc.  So I may have missed the magic
combination of priority bits.

In any case, because the precise behavior isn't well documented it
may not be a great idea to rely on a particular behavior.

> routers to strip the IP ToS bits on all packets received from
>  customers -- in order to  mitigate such threats.  This last practice
> is a de facto barrier to widespread  DiffServ deployment.

My experience is only ISPs doing MPLS mangle the ToS bits.  Since I used
to work with some IBM mainframes, which were ToS aware and got upset when
people munged the ToS bits, it was most annoying.

Although this may explain why we have recently (in the last 3 months)
started seeing attacks containing packets with port 179.  Before now I
didn't make the connection why they were sending BGP packets to things
that didn't talk BGP.  I was assuming (dumb mistake) the routers didn't
treat transit packets differently.  But if the routers prioritize BGP
packets over other packets, it would make a more effective DOS technique.

---

From: Bill Woodcock <[email-masked]>
Date: Thu, 31 Oct 2002 13:57:59 -0800 (PST)

> there is a maximum packet loss and delay for VoIP traffic, and
    > both are interdependent.  For delays of ~200ms, a corresponding
    > drop rate of 5% is deemed acceptable.  When delay is lower, a
    > 15-20% drop rate can be experienced and still considered
    > acceptable.  Regardless of a definitive drop rate, it would seem
    > that interactive voice has a lower threshold of loss than other
    > elastic applications.

No disagreement with any of that.  Have you, however, been able to find
any IP telephony (by your definition, SIP or equivalent) using site
pairs which are experiencing interconnection performance worse than
that?  The only connection we've been able to find which failed to
exceed PSTN quality was actually a satellite modem connection, so it
was, in effect, tunnelled through the PSTN.

And that was the link adjacent to the end-user, and was carrying no
other traffic. Thus no amount of QoS, dif-serv, SLA, et cetera would
have been of any help.

My operational experience tells me that that's a generalizable truth.
That unlike in the PSTN, in the Internet, if there's a path, it'll be
sufficient, and if there isn't a path, no amount of QoS will fix the
basic lack of ability to forward packets.

                                -Bill

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 31 Oct 2002 17:06:44 -0500

On Thursday, Oct 31, 2002, at 16:31 America/Montreal, Sean Donelan 
wrote:
>  Proteon routers were very much
> ToS aware, and ToS bits could make a significant difference.

I still miss my Proteons.  Agree.

> Treating the router as a black-box, our testing didn't show any 
> difference
> between packets with ToS bits and packets without ToS bits.

Interesting and useful data.

> may not be a great idea to rely on a particular behavior.

Fair.

> people munged the ToS bits, it was most annoying.

Interesting.

> packets over other packets, it would make a more effective DOS 

Ah.  I was unclear; my bad.  I'm not sure whether or not *transit* 
packets
are handled differently in a default router config these days.  I 
should have
said that on the receive-side *for packets destined to the receiving 
router*
there was (notional) intelligence to drop other packets rather than
drop incoming BGP packets.  As your tests didn't indicate it made much
difference, this implementation detail might not matter in practice.

Thanks,

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 31 Oct 2002 17:08:37 -0500

> to point to your uniqueness relative to the other Topologies.

I don't recall commenting directly on topologies.  So I find the above
pretty confusing and am not at all sure of your meaning.

Ran
[email-masked]

---

From: Bill Woodcock <[email-masked]>
Date: Thu, 31 Oct 2002 14:06:11 -0800 (PST)

> This problem is further compounded when toll-quality service is
    > expected because it assumes a default service model that is
    > better than best effort.  This in turn can increase the
    > probability that a form of call-blocking can occur with VoIP or
    > IP telephony traffic.

I'm not able to make sense of this.

What's meant by "toll-quality service?"  I'm perhaps incorrectly
reading that as "voice quality similar to that experienced by users of
the PSTN."  If that interpretation is as intended, it implies that the
authors believe that IP telephony on the commodity Internet doesn't
universally exceed that threshold.

                                -Bill

---

From: "Kelly J. Cooper" <[email-masked]>
Date: Thu, 31 Oct 2002 22:00:40 +0000 (GMT)

> people munged the ToS bits, it was most annoying.

I believe some ISPs are re-marking packets at the customer edge to
indicate higher priority for VoIP (and a 0 priority for everything else)
as well.

Regards,
Kelly J.
--
Kelly J. Cooper        -  Security Engineer, CISSP
GENUITY                -  Main # - 800-632-7638
Woburn, MA 01801       -  http://www.genuity.net

---

From: Bill Woodcock <[email-masked]>
Date: Thu, 31 Oct 2002 15:04:23 -0800 (PST)

> Primary Objectives in support of authorized emergency calls:
    > 2) Interaction with PSTN
    > The second objective involves the interaction of IP telephony
    > signaling with existing PSTN support for emergency related voice
    > communications.  As mentioned above in Section 1.2, standard
    > T1.631 [26] specifies emergency code points for SS7.
    > Specifically, the National Security and Emergency Preparedness
    > (NS/EP) Calling Party Category code point is defined for ISUP IAM
    > messages used by SS7 [26].  Hence, our objective in the
    > interaction between the PSTN and IP telephony with respect to
    > IEPS (and national indicators) is a direct mapping between
    > related code points.

This seems problematic to me, in exactly the same way as if a user came
before the IETF with a draft which stated that that their objective was
to have carriers peer. That's nice, but that's a business decision to
be made by the carriers, and it doesn't really serve any useful goal to
say that it's nice in an official IETF document.  This seems like
another statement of the "We like toast!" variety.

Simply stating that "interaction with the PSTN is a primary objective"
isn't going to get the PSTN carriers to run around buying connections
to all the different IP telephony networks, and I doubt the NCS would
be really happy paying the marked-up pass-through cost of doing so,
even if the telcos felt like doing it.

                                -Bill

---

From: Bill Woodcock <[email-masked]>
Date: Thu, 31 Oct 2002 15:44:32 -0800 (PST)

> 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.

                                -Bill

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 31 Oct 2002 19:15:34 -0500

On Thursday, Oct 31, 2002, at 17:00 America/Montreal, Kelly J. Cooper 
> indicate higher priority for VoIP (and a 0 priority for everything 

Very interesting.  Thanks for sharing.  Are those ISPs also deploying
support for IP ToS/DiffServ with multiple queues and so forth ?
Is the deployment large-scale in a production network ?

Learning more about actual deployment experience with such would be
very helpful for the discussion here, IMHO.

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 31 Oct 2002 19:18:27 -0500

On Thursday, Oct 31, 2002, at 18:04 America/Montreal, Bill Woodcock 
> even if the telcos felt like doing it.

Bill,

	To be fair, if NCS have budget to do it and think it is wise
use of their budget (and it doesn't contravene whatever rules govern
that budget), then I think that is their call to make -- not the IETF's 
call
-- for the same reason that you outline that "obtaining peering" is
a business decision among consenting ISPs rather than an IETF decision.

	I might share your sense that it is likely to be expensive,
but I strongly think IETF needs to stay far far away from telling
people what kinds of business those people may/should/must undertake
(or not undertake).

Ran

---

From: Bill Woodcock <[email-masked]>
Date: Thu, 31 Oct 2002 16:15:40 -0800 (PST)

> a business decision among consenting ISPs rather than an IETF decision.

Right...  So we don't have IETF documents saying that it's nice to peer,
and we don't have IETF documents saying that we like toast, and I don't
see that we should have IETF documents which say that it would be nice if
the PSTN connected to the rest of the world.  Sure, it would be nice, but
are they going to do it?  None of our business, in an institutional sense.

                                -Bill

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 31 Oct 2002 19:25:22 -0500

I know of work on voice over IP over low-bandwidth HF Radio
done by US Navy in the early 90s.  It worked fine.   The critical
thing to making it all work was to pick a robust/resilience vocoder
algorithm.  No QoS was needed.  And available bandwidth (for all
traffic) was a lot less than 1 Mbps.

	I'm not suggesting that VoIP is trivial to make work, just that
a lot of the anxiety about network QoS seems to be misplaced
given various experiments and various real deployments.  I think
getting the SIP bits working as intended can be pretty hard,
for example.

Ran

On Thursday, Oct 31, 2002, at 16:57 America/Montreal, Bill Woodcock 
wrote:
> No disagreement with any of that.  [...]

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 31 Oct 2002 19:31:46 -0500

On Thursday, Oct 31, 2002, at 18:44 America/Montreal, Bill Woodcock 

> other than that of the production traffic.

	And actually, this "requirement" is one driven by a PSTN-like 
architecture
where routing is NOT dynamic and instead is static, configured at call
setup time.  The Internet does not have that problem so doesn't need the
above "requirement".

	With the IP world's dynamic routing, the above requirement is not 
appropriate
or helpful to achieving better quality connectivity during a calamity.
The 9/11 calamity, several earthquakes, and sundry other disasters 
around
the world have shown that dynamic IP routing is nearly impossible to 
beat.
To give another example, the Iraqis reportedly used dynamic IP routing
to keep some of their command & control networks up and working during 
the Gulf War
-- despite extensive Allied bombing.

Ran
[email-masked]