Subject: RE: [Ieprep] access links

From: "Nguyen, An" <[email-masked]>
Date: Thu, 14 Nov 2002 09:34:32 -0500

Sorry I did not make it clear! What I really meant was the best effort is
not enough for emergency traffic because of the "best effort" nature in the
IP networks.

An

-----Original Message-----
From: King, Kimberly S. [mailto:[email-masked]]
Sent: Wednesday, November 13, 2002 6:38 PM
To: 'Nguyen, An '; ''King, Kimberly S.' '; ''Dean' '; 'RJ Atkinson '
Cc: 'ieprep '
Subject: RE: [Ieprep] access links 

An said:
>The problem with this is that you don't know the locations where
>emergency occurs  in advance. You can't provision your access links
>everywhere around the country. And that is not at all cost effective. 
>If there is no way of differentiating traffic, then the best effort
>traffic is best effort.

I read this statement as best effort transport is sufficient due to the
infeasibility of providing anything different.  

Those apposing the statement, please provide a feasible alternative.

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

---

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

> not enough for emergency traffic because of the "best effort" nature in the

Sorry, this is still far from clear.

Because of _what about_ the "best effort" nature of IP networks?

                                -Bill

---

From: "Steve Silverman" <[email-masked]>
Date: Thu, 14 Nov 2002 10:37:52 -0500

Bill,

You appear to have a difficult time understanding what we ("we
represents the DOD, many NATO defense ministries, and IMHO most of
the public network) need.  Let me make one more attempt to explain.

Some locations DO NOT have high bandwidth available (e.g., mobile
platforms on radio links).  Emergencies can happen anywhere  and in
such emergencies it is common for the offered traffic load to exceed
the network capability and it is necessary for selected users to get
priority.  This is a functional requirement, independent of the
technology of IP or any other network technology.  It is a JCS
requirement which means that the DOD (and various other
organizations can not deploy equipment that can not satisfy this
requirement.

While some have made a point that IETF attendees represent
themselves as individuals rather than the organization they work
for, it is also a fact that few of the attendees, pay their own way
to the meetings.  I currently am paid by the DOD and because I take
their money, and since I have considerable experience in meeting
their needs, I tend to focus on those subjects that they want.
Since I personally consider these needs to be legitimate
requirements, I have no conflict representing their views.  I doubt
that many of the attendees in Atlanta are without organizational
support and few if any organizations would support someone who
opposed their requirements.

The DOD has certain functional requirements.  Whether or not a few
people think these are "valid", if the DOD says it wants something
and is willing to pay for it, then they have a right to attempt to
buy it.
Since the DOD tries to maintain a multi-vendor environment (as a
taxpayer, I applaud this preference.) they try to get
standards to support their requirements.  If there are no such
standards, they have to write their own or stick to one supplier.
Many of us think that a public standard, even if optional and not
supported by some vendors and some networks, is preferable.

Many companies would like to be able to sell their equipment to the
DOD.  Some companies might not be interested in this buisiness.
That's fine.  We just want enough of a standard so that multiple
vendors can meet our requirements in an interoperable way.

As to the lack of a possible way to provide better service, Houston
Associates has built and tested a way to provide some users higher
priority. We intend to submit an Internet Draft (Multi-Level
Expedited Forwarding) for a new optional PHB that has been shown to
solve some of this problem.  Considerable work remains to be done in
terms of security but it will work well on a T1.  We are not worried
about lines at optical rates (above E1). These don't generally share
the problem of lack of  bandwidth.

I think this function MIGHT be useful for the public network but my
priority is to get this function available for special private
networks, not the public net.

Steve Silverman
Houston Associates

-

                                -Bill

I

---

From: Bill Woodcock <[email-masked]>
Date: Thu, 14 Nov 2002 08:07:44 -0800 (PST)

On Thu, 14 Nov 2002, Steve Silverman wrote:
    > You appear to have a difficult time understanding what we need.

No, I have a hard time understanding why it is you think I should care.

    > technology of IP or any other network technology.

So why do you think that the experience you're referring to, which is
circuit switched, has any applicability at all in a packet-switched
environment?

Moreover, why should DoD "requirements" matter to me?

You guys keep repeating this "we've determined that we require foo" over
and over, seemingly without recognizing that it's making just as little
impact now as it did the first hundred times.  If you can show that
there's a problem, and that the problem is tractable, then someone might
take you seriously.  Until then, we're all just going to continue to
wonder why you keep repeating yourself.

    > It is a JCS requirement which means that the DOD (and various other

Hey, if you're the one they're paying, then it sounds to me like their
requirements are your problem, not mine.

    > I doubt that many of the attendees in Atlanta are without
    > organizational support and few if any organizations would support
    > someone who opposed their requirements.

Then you'd be wrong on both counts, as numerous IETF folks have pointed
out on this list already.

You guys are in this tight loop with DoD procurement folks or whatever,
all trying to mutually justify each others' existence, and dragging us
into the middle of it just wastes everyone's time.

                                -Bill

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 14 Nov 2002 19:52:34 -0500

On Thursday, Nov 14, 2002, at 10:37 America/Montreal, Steve Silverman 
> opposed their requirements.

Several of my employers, including NRL and DoD, have done so now and
in the past.  Giving away free crypto code was contrary to government
policy in the mid-90s, but I did just that under funding from ARPA
and SPAWAR, to give one example.[1]

> The DOD has certain functional requirements.

This is "requirements" in the meaning of "objectives or goals",
not "requirements" in the IETF sense of something one must
implement or deploy.  Getting our terminology differences straight
WILL help us all communicate better, IMHO.

> Whether or not a few

Please do.  Please don't use an IETF WG as political/marketing
air cover for that attempt.

> DOD.  Some companies might not be interested in this buisiness.

This is a good point for me to mention that my views are most
definitely NOT my employer's views on any number of topics.

> the problem of lack of  bandwidth.

That is a MUCH more helpful approach than *anything* happening in
this WG, IMHO.

Ran
[email-masked]

---

From: Scott Bradner <[email-masked]>
Date: Thu, 14 Nov 2002 20:18:06 -0500 (EST)

> opposed their requirements.

I do not think the issue is who pays the hotel bill unless one   of the
conditions for getting the bill paid is to leave one's brain     on the
night stand back at home

it is *very* helpful to understand what organizations think their
requirements are in any IETF-related area - such organizations are the ones
that will be using (or trying to use) IETF protocols

but two things

1/ requirements need to be evaluated for their technical feasibility and
general usefulness - they not evaluated based on who said they  have the
requirements - requirements from individuals, small companies, big
companies, governments or the military will all get evaluated for their
technical feasibility and general usefulness

2/ it is very helpful if the people in the working group, including  those
people from organizations who have sent requirements to the IETF, are free
to openly discuss the issues around the technology and are not limited in
their mandate to just push a corporate line

when people say that people are here as individuals they mean that it will
not add to the strength of an argument (a technical point or requirement
for example) to say that big-co supports it - and is generally seen
as a sign of a poor technical position

to me the key phrase in the quote is "I personally consider these needs to
be legitimate requirements" - that should be the focus of the  discussion
not what the source of the requirements might be

requirements MUST NOT be dismissed just because they come from a
particular organization and they MUST NOT be accepted just for a similar
reason

Scott

---

From: Bill Woodcock <[email-masked]>
Date: Fri, 15 Nov 2002 00:28:39 -0800 (PST)

> WILL help us all communicate better, IMHO.

Oh, come on, Ran, there's such a thing as being too conciliatory, you
know?  This is just ridiculous.  If someone doesn't know what a word
means, saying that you'll excuse them on the basis of cultural relativism
and coming to a compromise where you halfway-accept their misuse doesn't
do them a favor.

"Requirement" means something compulsory, requisite, necessary, compelled.
Not someone else's passing whim.

                                -Bill

---

From: "Steve Silverman" <[email-masked]>
Date: Fri, 15 Nov 2002 08:07:40 -0500

Bill,
Thank you, you are correct.  These are necessary functions (which
already exist) without which, the new technology can not be adopted.

Steve

> From: Bill Woodcock [mailto:[email-masked]]
> Sent: Friday, November 15, 2002 3:29 AM
> To: RJ Atkinson
> Cc: Steve Silverman; 'ieprep '
> Subject: Re: [Ieprep] representation & IETF culture
>
>

.....

---

From: Rex Buddenberg <[email-masked]>
Date: 15 Nov 2002 10:43:36 -0800

> Not someone else's passing whim.

Not in the government, Bill.

You've obviously never had your government acquisition lobotomy.

The intellectual root (ignoring the cultural and legal aspects for a
moment) lies in the difficulty in defining requirements.  We're all
educated as problem solvers ... think of the last test question you
worked on.  
     Few people get the feel for looking at a set of symptoms and
divining the root problem(s) several layers deep.  This is a
particularly hard exercise when you're dealing with disruptive
technologies and this is an instance where Internet technology is
definitely disruptive.

In theory, DoD requirements are supposed to come from the field -- the
combatant commanders.  These then go to JCS who shepherds a set of
capstone requirements documents through the system that are supposed to,
top-down, drive several operational requirements documents.  If you
caught it, we just went through not one, but two many-to-many
relationship knotholes.  
	There are two egregious corruptions of the system that tend to occur
here:
	- the 'requirements' tend to come in the form of 'buy me this solution'
rather than 'solve this problem', opening the door for all kinds of
brochure-engineering. We're seeing it in the form of 'make GETS work
over the internet' rather than how can the internet support emergency
services better.  
	- the poor articulation of field requirements is 'compensated' by some
entity in DC (lobbyists included) ghosting the requirement.  The terms
'empire building' and 'self-licking ice cream cones' have appeared to
describe this phenomenon.  The result is that we solve problems we know
how to solve, not the ones that need to be solved. (reprise the
disruptive technology comment). To be fair, this synthesis is often
vital for scalability reasons so simply proscribing it won't help.

Government, unlike commercial business, doesn't have the profit/loss
correction mechanism on such behavior.  So we keep trying to reinvent
other means; so far,in the history of the republic, we've been
unsuccessful.  (You can observe that Stalin was markedly less successful
at the same game).

All this is compounded by the government's inability to maintain subject
matter experts in-house.  Without getting into the reasons why, one
solution to this problem is to hire engineering support contractors. 
The trap that occurs here is that the contractor ends up doing what it
says in his contract (he wants to be paid and he wants the contract to
be renewed so he gets paid next year too).  And that incentive can be
strong enough that the contractor will tell the government agent what he
wants to hear rather than what he needs to know (in the vernacular, the
contractor is in stoop&fetch mode). The system is not designed for
intellectual honesty, regardless of the integrity of the individuals
involved.  
	An additional impediment along the way is that the government doesn't
let just anybody spend the taxpayers' money -- you have to be a
Contracting Officer to do that (and have a 'warrant' -- apt term, don't
you think?) in your possession authorizing you to do so.  So when the
program manager latches onto a KO ('CO' means commanding officer, thus
the re-alphabetizing),who's had all the requisite acquisition training,
the one thing you can rely on is that the clue density between them will
not go up.  

Want an illustration (this is a sea story alert)?  Few years ago, one of
my thesis students was working on a mine warfare problem.  The first
need for countering sea mines is to know where they are.  Then 1) you
tell the rest of the world where not to go and 2) you can tell your mine
clearance guys where _to_ go.  The tactical means to do this is to drag
a side-scan sonar behind a helicopter and take pictures of the ocean
bottom -- if something goes BANG, it's the sonar, not the helo.  The
problem was that the data (in the form of TV pictures) stayed in the
helo until it landed and the videotapes were sneakernetted off to the
opcen to be reviewed.  
	After going through the DC requirements mill, the 'requirement' came to
my student as 'we need full motion video over the horizon'.  Which you
should recognize as rather expensive and impractical.  Fortunately, at
thesis time, we have about as many counters to the silly requirements
exercise in place as there are likely to be.  Once we got an actual
videotape (cleanup of Persian Gulf after the war -- densest minefield US
Navy has dealt with since Korea), we were able to peel off a couple
layers of the onion:
	The data isn't really full motion at all -- use of NTSC video was
simply an engineering convenience.  
	Further, about 90% of the ocean bottom was featureless sand -- zero
interest.  All we really need is snapshots of areas of interest (mines
and tolerance for a fairly high false alarm rate). 
	 That banged the bandwidth requirement down to a size that would fit
through the 3kHz HF radio that's already installed in the aircraft.  

So one of the ID exercises is to peel off the onion layers and figure
out what the problem is.  IETF is better than the average bear at this
-- the continuing opportunity for charter-bashing is one of the
artifacts.  Allows us to think about whether or not we're solving the
right problem.

---

From: Bill Woodcock <[email-masked]>
Date: Fri, 15 Nov 2002 11:20:12 -0800 (PST)

> Not in the government, Bill.

No, in the English lanugage, which is our one hope for bridging this gap.
If we don't share a common language, I'm hard-pressed to imagine a way of
discovering commonalities of understanding and belief.

A little REQUISITE reading for anyone who doesn't believe this is a
really serious problem:
http://dogbert.abebooks.com/servlet/BookDetailsPL?bi=74999286

...and then Rex went on to say about three more pages about the process
of scientific inquiry which I agreed with.

                                -Bill

---

From: Bill Woodcock <[email-masked]>
Date: Fri, 15 Nov 2002 11:27:40 -0800 (PST)

> already exist) without which, the new technology can not be adopted.

Okay, next step of the exercise: form whom are they necessary?

                                -Bill

---

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

> Okay, next step of the exercise: form whom are they necessary?

Oh, and while we're at it, let's replace the phrase "These functions" with
some specific noun.  "QoS control?"  "Service level agreements?"
"Specialness?"

                                -Bill

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 15 Nov 2002 20:46:01 -0500

> discovering commonalities of understanding and belief.

We don't currently share a common language.  I can speak both languages,
as an artifact of a previous job for Navy, but the 2 communities here 
have
very different meanings associated with "requirement".

I tried to explain this earlier on.  Here's an attempt at a replay:

In IETF, "requirement" means something that an implementer MUST 
implement
and/or something that an operator MUST deploy.

In USG, "requirement" means something that the USG needs, seeks,
or desires.  In the government, it is often the case that someone comes
to the table with a "requirement", but is satisfied with something
entirely different or goes away with the "requirement" unmet.

In this WG, I'd suggest we all try hard to use the IETF definition, 
because
this is an IETF WG.  I understand that a large number of the documents
being discussed here will be edited to use IETF definitions (probably
won't appear online until after Atlanta due to I-D cutoff and lack of
time to do the editing just now).

Rex's story is very very good and is worth re-reading.  Part of what 
some
of us are trying to do is figure out if the priortisation is really
"full motion video" of Rex's story.  I'm currently strongly inclined to
think that it is and that we need to sort out what the equivalent of
the "selected still photos" of Rex's story might be in this context.

Ran
[email-masked]

---

From: "Steve Silverman" <[email-masked]>
Date: Fri, 15 Nov 2002 21:01:50 -0500

Bill,
As to the users who require these services, the DOD has had such a
system for 40 years and
they already have a way to determine the recipients of the service.
I don't worry about the details of this.

As the functions, while good voice quality is nice, it isn't
paramount.  They key function is high probability of
call completion in a congested environment.  Even if the offered
traffic load exceeds the network capability, the selected users
calls get through.  Even if the voice quality is less than normal,
if it is reasonably intelligible, it is sufficient.
High probability of completion is accomplished by MLPP in the CS
network.  As I understand it, this is essentially what GETS does in
the public network.

Steve Silverman

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> Bill Woodcock
> Sent: Friday, November 15, 2002 2:48 PM
> To: Steve Silverman
> Cc: RJ Atkinson; 'ieprep '
> Subject: RE: [Ieprep] representation & IETF culture
>
>

---

From: Bill Woodcock <[email-masked]>
Date: Fri, 15 Nov 2002 18:13:53 -0800 (PST)

On Fri, 15 Nov 2002, Steve Silverman wrote:
    > The DoD has a way to determine the recipients of the service.

Mmmm, while I'm sure that's normally beneficial in reducing the number of
things you have to worry about, at the moment you need to be selling us on
the desirability of paying attention to these documents or desires or
whatever...  So if you don't know who it is that might actually need or
want the services the document describes, you might consider:

a) making up something plausible and running with it,
b) finding someone who does know, and have them tell us, or
c) adopting Rex's explanation of who the users should be.

    > They key function is high probability of
    > call completion in a congested environment.

Okay, that's a really good simple statement of a reasonable and
desirable goal, made in a style which is palatable to IETF folks.
If you can get consensus from your side, let's go with that for now.

    > These are necessary functions (which already exist) without which,
    > the new technology can not be adopted.

Okay, so this could now be refined to:

"High probability of call completion in a congested environment is a
necessary precondition of VoIP adoption by [a presently unidentified user
community known to the DoD]."

...but since the IETF doesn't care whether people use particular products
and services, per se, that would be at least as effective if further
simplified to:

"High probability of call completion in a congested environment is desired
by [a presently unidentified user community known to the DoD]."

This starts to be self-evidently a common good.  If you can present your
case in such a way that it's recognized by the recipients of your argument
as being a common good, one which they themselves will in fact benefit
from, everyone will be on your side, and you won't have to actually make
much of an argument.  Which is how you want to deal with the IETF.  It
doesn't stay that simple once people start hammering out the details of
protocol changes, but it's the best place to start.

I'm assuming for now that the phrase you choose to replace the presently-
unidentified-&c. will be something like "emergency services personnel."

                                -Bill

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 15 Nov 2002 21:44:55 -0500

On Friday, Nov 15, 2002, at 08:07 America/Montreal, Steve Silverman 
> already exist) without which, the new technology can not be adopted.

Does this mean we get lucky, you all give up now, and we can go back
to building a better Internet ?

Ran

---

From: Bill Woodcock <[email-masked]>
Date: Fri, 15 Nov 2002 18:44:06 -0800 (PST)

> to building a better Internet ?

I think he meant (and see the edited version of this sentence in a
different email) that these functions exist in the PSTN, and were believed
to also be necessary in the Internet before unidentified users could adopt
inter-domain VoIP.

                                -Bill

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 16 Nov 2002 10:45:48 -0500

>
> In IETF, "requirement" means something that an implementer MUST implement
I think it's actually somewhat more subtle than that. We essentially 
have at least three requirements, even though the language of RFC 2119 
only covers one of these. This is partially due to the fact that the 
protocol development approach in the IETF has changed in practice, at 
least in high-activity or contentious WGs, without this having been 
formally documented.

One way to slice this is by looking at this as three levels of indirection:

(1) We have requirements in protocol definitions, generally expressed as 
MUST, MUST NOT (and maybe SHOULD), according to 2119, as in:

  MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
    definition is an absolute requirement of the specification.

These are requirements to implementors of the protocol.

(2) We have requirements that a protocol *definition* needs to fulfill. 
For an example I'm familiar with: All new protocol definitions for SIP 
now have to go through SIPPING, which simply writes a requirement 
document, which is then handed to SIP for the actual protocol work. This 
document may use the same MUST, MAY or SHOULD terminology in 2119, but 
this is a meta-requirement for the protocol, not for an implementor - 
there is no protocol yet to implement. A MUST simply means that every 
protocol candidate has to satisfy this requirement or it's out of the 
running. This level of requirement does not address the fundamental need 
or many of the surrounding assumptions. For example, the NSIS 
requirements assume it as a given that we'll need a protocol to 
establish layer-3 state in the network and the question is simply what 
consequence this goal has when translated into finer-grained questions. 
If you disagree with the goal, speaking up at WG charter time would have 
been the appropriate moment.

In IEPREP, I believe that my SIP-related document roughly falls into 
this category.

(3) We have requirements for certain functionality in the network. In a 
sense, this is one more step removed from (2). It simply says "if a 
network wants to support this user-level functionality, it should have 
the following properties or offer the following services". This is not 
something that the IETF has done much of. It leaves the solution space 
relatively open, although in reality the requirements may constrain the 
space to a fairly narrow one. Some of these are BCPs, but some are more 
forward looking, in that there is no "best" and no "current" practice to 
document yet.

In searching for "requirements" in existing recent RFCs, we get a pretty 
good sampling of all of these; below, I labeled them with (2) or (3) 
according to the above. Clearly, most are in the (2) category. Every 
protocol spec citing 2119 is in category (1).

3386 Network Hierarchy and Multilayer Survivability (3)

This document presents a proposal of the near-term and
practical requirements for network survivability and hierarchy in
current service provider environments.

3384 Lightweight Directory Access Protocol (version 3) Replication
Requirements (2)

3379 Delegated Path Validation and Delegated Path Discovery Protocol
Requirements (2)

3375 Generic Registry-Registrar Protocol Requirements (2)

3365 Strong Security Requirements for Internet Engineering Task Force
Standard Protocols (2)

3354 Internet Open Trading Protocol Version 2 Requirements (2)

3351 User Requirements for the Session Initiation Protocol (SIP) in
Support of Deaf, Hard of Hearing and Speech-impaired Individuals (3)

3304 Middlebox Communications (midcom) Protocol Requirements (2)

3327 Requirements for Reliable Server Pooling (2 or 3)

3172 Management Guidelines & Operational Requirements for the Address
and Routing Parameter Area Domain ("arpa")

Maybe explicitly saying "user requirements" (3) and "protocol 
requirements" or "requirements for protocols" (2) might help to make 
this clearer.

We also have documents that then assess candidate protocols, 
particularly in areas that are contentious (midcom and AAA come to 
mind). I suspect that having us be explicitly aware of this three-step 
might at least help us to keep our document goals straight. For example, 
user requirements here might be
- use regular Internet service for emergency communications
- work with the full range of access speeds
- support VoIP at a certain quality level, citing relevant quantitative 
traceable requirements
- deal with situations where the network is under deliberate attack
- deal with situations of resource scarcity and applications that have 
different value (or different levels of authentication)
etc.

These are just examples to give a flavor of what I have in mind.

In a document then written by Ran and Bill (and hopefully others), 
possible tools/mechanisms/protocols can be assessed as to why they work 
or don't work (or, probably more often, where they might work and where 
not). Here, we probably have to distinguish between things that are 
implementable if somebody considered it important and limitations of 
today's equipment. (Random example: packet filtering for DOS attacks is 
probably not implementable on today's deployed routers, but this does 
not imply that we should stop working on the technology.)

If there's a gap, we go back to requirement (2), with a concrete 
protocol in mind. If there's an existing WG, it becomes input, if 
there's not, it becomes a BOF charter :-)

Does this make sense?

Henning