Subject: FW: [Re: [Ieprep] ieprep-requirements-01 - reqs 6-10 - discussion request]

From: "Gary Thom" <[email-masked]>
Date: Fri, 8 Nov 2002 15:04:43 -0500

> -----Original Message-----
> From: Gary Thom [mailto:[email-masked]]
> Sent: Friday, November 08, 2002 3:03 PM
> To: RJ Atkinson
> Subject: RE: [Re: [Ieprep] ieprep-requirements-01 - reqs 6-10 -
> discussion request]
> 
> 
> Incorrect. NCS is an executive branch organization that sits 
> between the DOD and other federal agencies(including FEMA). They 
> are not a part of DISA and not a part of DoD. They do have 
> resposonsibility for coordinating communications between the DoD 
> and these other federal agencies, and state and local agencies. 
> You are correct though, it will be reorged into DHS.
> 
> The goal is not to make the internet to look like the PSTN. The 
> goal is to provide high probability of call completion in 
> telephone (IP OR Circuit switched) systems. It does not need to 
> be done the same way it is done in the PSTN.
> 
> Many people have these grand ideas that this will be used on the 
> "Public Internet". I personnally think it is more important and 
> more practical to consider this capability for use on IP networks 
> which are used to provide telephony services. These networks 
> generally interconnect with the PSTN because they are providing 
> public telephone services. My focus is on that application, but 
> like I said, others think it should extend to the public internet 
> and include priority for email, chat, etc. I beleive that this is 
> impractical and that the public internet can be used as in on a 
> best effort basis. But the IP and PSTN are different, and a lot 
> of good can come from being able to provide priority service for 
> disaster recovery.
> 
> The Japanese IAA is a different type of service, and is not 
> conversational, so the Internet may provide sufficient capability 
> without change.
> 
> As far as being US centric, maybe it is, but it is a good idea, 
> that will provide world wide benefit, and in fact, mast disaster 
> recovery operations are being supported internationally 
> (principally involving the US and a few western european 
> partners), and the ITU has acknowlegde the benefit of providing 
> international priority communications to support there global 
> efforts. So the fact that this is being driven by the US, does 
> not mean it only has a US benefit.
> 
> Again, my focus is on public telephony. I agree that there may be 
> some who are streaching this to other iP applications, and I 
> think they are misguided. However, this WG is focused on SIP 
> which does address telepony, so I think we should find a way to 
> develop this work in a technically efficient manner.
> 
> 
> Thanks
> Gary
> 
>  --------------------------------------------
>  Name   : Gary A. Thom
>  Company: Delta Information Systems, Inc.
>  Address: 300 Welsh Rd., Bldg 3
>           Horsham, PA 19044 USA
>  Phone  : +1-215-657-5270 x123
>  Fax    : +1-215-657-5273
>  E-mail : [email-masked]
>  Website: www.delta-info.com
> --------------------------------------------
>  
> 
> > -----Original Message-----
> > From: RJ Atkinson [mailto:[email-masked]]
> > Sent: Friday, November 08, 2002 2:21 PM
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: Re: [Re: [Ieprep] ieprep-requirements-01 - reqs 6-10 -
> > discussion request]
> > 
> > 
> > 
> > On Friday, Nov 8, 2002, at 10:52 America/Montreal, Gary Thom wrote:
> > > Also, realize that Hal's work is not specifically DoD centric,
> > 
> > NCS is part of DoD (until reorg'd into DHS).
> > By its very definition it is DoD-centric.
> > 
> > Further, it is tremendously US-centric (e.g. compare with Japan,
> > where ISPs have done zero/zip/nothing to support IAA because the
> > Japanese Govt adapted the IAA activity to the Internet -- rather than
> > trying to make the Internet look like the PSTN).
> > 
> > Ran
> > 
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: Bill Woodcock <[email-masked]>
Date: Fri, 8 Nov 2002 12:17:57 -0800 (PST)

> The goal is to provide high probability of call completion in
    > telephone (IP) systems.

I missed the part in which someone presented some evidence to support your
misassumption that this goal hasn't been met.

                                -Bill

---

From: "Gary Thom" <[email-masked]>
Date: Fri, 8 Nov 2002 15:45:54 -0500

> misassumption that this goal hasn't been met.

If it has been met, a simple statement of this capability will eliminate a
lot of continuing aggravation.

As I said before, there are two issues:

The first is whether the network (and associated elements such as routers
and switches) can provide priority transport of packets associated with an
emergency call. I am not qualified to address this, so I defer to others as
to whether this is a problem or not, but certainly there is a desire to give
some preferencial treatment to those packets in the event of congestion or
degrated operation.

The second is whether the telephony elements (such as SIP proxy servers,
redirect servers, etc) are informed that a particular call is an emergency
call so that those elements can take action to improve the proboability of
call completion. For example, to loosen addmission policy to allow an
emergency call even though other addmission criteria may not be satisfied.
The actual action to be taken is certainly a local matter and not subject to
standardization, however, the signalling within the protocol to indicate an
emergency call should be done in a standardized way. At least this part
should be communicated with the proper WG in order to enhance the SIP
protocol.

gary

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 8 Nov 2002 16:16:06 -0500

> some preferencial treatment to those packets in the event of 

They don't need priority transport.  Enough of them do need to get
through that the vocoder algorithm in use can maintain sync and
that the user can understand the converation.

Bill's VoIP network is pretty large.  He has consistently reported
that he isn't having problems -- with no special treatment needed.
I don't know what vocoder algorithm he's using and my own prior
life experience indicates that probably matters.

Ran
[email-masked]

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 8 Nov 2002 16:19:05 -0500

On Friday, Nov 8, 2002, at 15:04 America/Montreal, Gary Thom wrote:
>> are not a part of DISA and not a part of DoD.

The Director of DISA is now (and always has been since at least
the founding of DCA, which is the old name for DISA) concurrently
the Director of NCS.  NCS is run functionally as a component
of NCS, just as WHCA has been run functionally as a component of
DISA.  Bottom line is that NCS is part of DoD for all intents
and purposes here.

It does appear that NCS will be re-homed by Congress into DHS,
but that hasn't happened yet according to The Washington Post,
so my statement stands as originally made.

Ran

---

From: "Gary Thom" <[email-masked]>
Date: Fri, 8 Nov 2002 16:28:13 -0500

Ran,

Thanks for your reply.

One thing to remember, is that we are really looking at operating under
non-normal conditions. This may be due to an unusually high load or with
degraded capability. During an emergency, such as a huricane or earthquake,
not only will you have everyone trying to find out if their loved ones are
ok, but you may have loss of bandwidth or or other error conditions due to
damaged equipment, fiber, etc. In this situation, we want to give emergency
communications an advantage.

gary

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 8 Nov 2002 20:13:58 -0500

> communications an advantage.

Gary,

	Would you consider 9/11/2001 to be "non-normal conditions" ?
As someone with a number of friends who work daily in the Pentagon,
and several parish members who died that day, I'd say that day was
pretty unusual.

	During that day, a few content providers had problems delivering
all the requested content.  In at least some cases, this was server
overload.  However, careful analysis of traffic logs by large ISPs
afterwards confirms that the Internet performed brilliantly.  Despite
fibre cuts in lower Manhatten and numerous environmental problems at
Hudson Street, the Internet automatically re-routed around the damage
and kept going.  And the large ISPs did NOT (repeat did NOT) start
dropping packets because of the cut fibres -- their backbones were
carefully over-engineered so the traffic was re-routed around the
lost links.

	Access to the US NASA feeds of the mars lander landing was a bigger
problem in Internet terms, yet even then the problems were on NASA's
access links and its servers, rather than in any large ISPs network.

	To me, the key thing is that the critical traffic gets through.
Saying that it must be "prioritised" implies a specific mechanism for
prioritisation.  It is better for us to focus on the real requirement
of the traffic getting through, than on specific mechanisms (in your 
words,
prioritisation) which might not be (probably aren't) needed, create new 
attack
vectors on the ISP network, and increase operational complexity.   There
is a significant body of evidence that a better (and lower-cost) 
approach
is to over-engineer the network so that the network simply can handle 
all
the offered load.

	I spent a fair bit of time yesterday talking with folks from major
ISPs.  One is a large inter-continental ISP with POPs located in 
Asia/Pacific,
North America, and Europe.  Another is based in Japan.  (etc.).  In
each case, they indicated that their backbone links are significantly
overprovisioned (max load << (50% link capacity)).  A typical number 
that
was mentioned was that links have a "max load" equal to 30-35% of link 
capacity.
They also noted that they have significant path diversity in their 
networks,
specifically including physical fibre path diversity.  This was 
originally
done as defence against back-hoe equipment, but it happens to work 
really
well during other kinds of natural/unnatural problems as well.  To give
another example, there was a fibre cut near Baltimore a while back.  It
cut several fibre bundles from different carriers.  The IP routing 
system
just automatically detected the link-down state and routed around the 
cut links
-- and there was enough spare capacity in the other links that there 
was no 
significant loss of service.

	Claims of the form "the Internet gets congested and drops packets
when an emergency happens" currently lack credibility, because they are
contrary to the measured, scientific data that we happen to have.  I'd
be much more inclined to take those claims seriously if someone would 
show
up with specific measured data about an actual incident.  And in that 
case,
it would be important to have enough specifics to actually sit down and
analyse precisely what happened -- without a great deal of detail this 
WG
is unlikely to correctly and clearly characterise the issue so that 
another
IETF WG to figure out what the correct protocol change(s) might be or 
for ISPs
to figure out which existing mechanisms might be candidates for broader
deployment.

	It would also be helpful if going forward we could clearly separate our
sundry concerns into the different layers of the Internet Architecture 
(Physical,
Link, IP, Transport, Application).[1]

Ran
[email-masked]

[1] The Internet Architecture is not identical to ISO OSI Model.  For 
example,
we have no Session Layer in the Internet.

---

From: Scott Bradner <[email-masked]>
Date: Sat, 9 Nov 2002 10:33:28 -0500 (EST)

this is a bit long but I hope will make some things clearer

> some preferencial treatment to those packets in the event of congestion or

making the assumption that for whatever reason there is not enough capacity
in an ISP's network to deal with all of the offered traffic load during an
emergency - the likelihood of this being the case will be different in
different parts of the world and for different ISPs

and making the assumption that we are talking about a single ISP (dealing
with the issues of coordinating any kind of support for non-best-effort
traffic between ISPs is a very hard problem that will not be solved in the
ieprep WG)

the simple answer to the first part of the first issue is that routers can
provide priority transport of packets, they have been able to do so  for
quite a while.

Routers can use the precedence bits in the header of IP packets to find out
what relative priority specific traffic should be processed at

But it is far from clear that this is what an ISP would want to do with
ieprep traffic - ISPs have regular customers which need to be able to
continue to communicate in cases of emergency - a strict priority-based
system where the ieprep traffic got absolute priority could easily starve
the traffic from the ISPs regular customers - 

it is my opinion that those ISPs who decide to offer ieprep service (for
lack of a better term) will set aside *some* of their capacity to support
this service offering - if the ieprep demand exceeds the capacity reserved
for it then there will be degraded service - exactly the same as if the ISP
were to dedicate all of their capacity  and the demand exceeded the
physical capacity  of the ISP's network

because of this I do not think that "priority" is even the correct concept
to be talking about - I think that "special handling" is about as close as
we can get to what might happen in the real world

In addition, any pure priority-based service is *very* vulnerable to denial
of service attacks - an attacker can send lots of traffic marked as ieprep
traffic which will result in the ISP not being able to delever any traffic
at all

 some routers can also use RSVP to reserve capacity for particular flows or
diffserv to differentiate traffic into different classes (note that most
difserv classes are not strictly priority) - these technologies may be a
far better bet to support ieprep that a pure priority-based approach

the simple answer to the second part of the first issue is that the routers
do not know what applications are transmitting packets  so the *router* can
not tell which packets are associated with an emergency call - something
will have to tell the router which packets are associated with a particular
flow (using RSVP for example) or mark the packets associated with an
emergency call in some special way (using diffserv for example)

> should be communicated with the proper WG in order to enhance the SIP    

as far the second issue:  I do not understand what SIP proxies etc would do
differently if they were told that a call was an ieprep call - I expect
that SIP servers/proxies etc will have plenty of processing capacity to
deal with processing all SIP calling requests that they receive (I suppose
the operator of a SIP network could decide to use old 33MHz 286 DOS
machines for their SIP servers but aside from that possibility it does not
seem realistic to think that SIP servers would need to pay attention to any
ieprep indication in terms of avoiding overload.

The suggestion is made that admission policy could be loosened for
emergency calls - this seems particularly risky in terms of providing
opportunities for denial of service attacks - unless one postulates a
totally reliable and unbreakable authentication mechanism for the users of
ieprep services which users will reliability have with tem when they need
to make an ieprep call.

I am not sure what one would change in SIP to deal with this issue beyond
what is already in Hennings SIP requirements document

Scott

---

From: Bill Woodcock <[email-masked]>
Date: Sat, 9 Nov 2002 08:21:34 -0800 (PST)

On Sat, 9 Nov 2002, Scott  Bradner wrote:
    > I do not understand what SIP proxies etc would do differently if
    > they were told that a call was an ieprep call.

I can't imagine any different handling would be needed within the SIP
infrastructure, however the receiving SIP end-station quite likely would
want to handle the calls differently.  Un-mute the ringer and set it to
maximum volume, dump the last low-priority call-appearance in the event
that the phone is limited to a specific number of simultaneous
call-appearances, and use some more intrusive form of call-waiting
notification than is usual.  If the end-station is an auto-attendant,
perhaps provide operator notification that an emergency call is being
progressed, and give the operator the option of breaking in to handle it
personally.  Move emergency calls to the head of any hold queues.  Provide
a different (and presumably simplified) user-specified option tree.  If
the end-station is voicemail, have it mail the result with a higher SMTP
priority, and exercise all delivery options simultaneously and at once.

But all of this is vendor-specific, and up at the application layer.

This is the sort of stuff User Services was particularly good at, and
exactly the reason I think it shouldn't have been shut down.

                                -Bill

---

From: RJ Atkinson <[email-masked]>
Date: Sat, 9 Nov 2002 11:40:09 -0500

On Saturday, Nov 9, 2002, at 10:33 America/Montreal, Scott Bradner 
> what relative priority specific traffic should be processed at

No disagreement with the above from me.[2]  It does carefully sidestep 
discussion
of operational considerations, which I'll try to address briefly in 
this note.

There are some unresolved issues with using IP ToS bits to sort out 
packet
precdence or drop preference.  I am unable to locate any *confirmed*
large-scale deployment of DiffServ by a commercial ISP.[1]  There are 
some
limited scale deployments, mostly in campus or research networks.  So
there are a bunch of operational/deployment issues with DiffServ that
appear to be unresolved.  Those would need to be fully resolved before
one could reasonably expect DiffServ to be widely deployed by commercial
ISPs.

[1] Of press releases or news accounts claiming such, none that I've 
been
able to track down in detail have turned out to really be DiffServ.  
There
are a couple that I'm currently trying to track down in detail to see if
they might be real DiffServ in a real production large-scale commercial 
ISP.

[2] Scalability of the implementation of this feature in a particular 
router
does vary greatly from router to router.  To deploy this, an operator 
would
need to perform appropriate equipment tests and might need to change 
some
routers for others that are better able to forward traffic while this 
feature
is enabled.  CPU-based routers are at a disadvantage to ASIC-based 
routers,
for example, though CPU-based routers are sometimes lower capital cost.

> traffic which will result in the ISP not being able to delever any 

And per-packet cryptographic authentication prior to forwarding is not
computationally feasible in an IP router today -- and certainly not 
anytime
soon for any large or medium percentage of packets.

> far better bet to support ieprep that a pure priority-based approach

The operational experience with RSVP is that it creates too much flow
state in routers, decreasing reliability/availability of the network
overall.  Given the operational experience in the limited deployments
of RSVP so far, RSVP seems unlikely to ever be widely deployed by a
commercial ISP as a regular (i.e. non experimental) service.

Ran
[email-masked]

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 09 Nov 2002 11:50:47 -0500

Since magic miracle vocoders come up all the time, it might be useful to 
   refer to the published literature on the topic. We have done a fair 
amount of listener evaluation of commonly used codecs and their 
sensitivity to (bursty) packet loss. See 
http://www.cs.columbia.edu/~wenyu for some papers on the subject. 
References therein will lead to a large number of related studies. I 
would appreciate pointers to published studies that provide additional 
or conflicting data.

By simple logic, no vocoder, however evolved, can cover losses that are 
long enough to delete significant portions of a syllable or word, unless 
you're willing to tolerate delays that turn interactive voice 
communications into voice messaging. Anybody is obviously free to 
operate their network in a way that offers only 
email-with-voice-attachments under overload; I don't think it is helpful 
to say that nobody should be operating a network that offers service 
that it better than that or that it is illegitimate to look at 
techniques that improve the quality of high-value communications at the 
expense of lower-value communications. I think it is useful to evaluate 
tools even if not everybody wants to use them or if they are not 
appropriate everywhere.

If a particular technique is never helpful, has been superceded by 
better tools or has severe "side-effects", we should document those 
issues and then leave it up to operators to make operational judgements 
that weigh the pros and cons.

As admirable as the PCH network is, it is rather small and homogeneous 
in the global scheme of things, with O(100) nodes. All available 
evidence indicates (see Infocom 2002 paper "Assessment of VoIP quality 
over Internet Backbones" 
[http://www.ieee-infocom.org/2002/papers/355.pdf], papers by Maxemchuk 
and Lo in ICC 1997 and any number of "Internet weather" sites) that 
congestion-induced impairments of network quality are common and real. 
Just saying that "most" conversations work just fine isn't particularly 
helpful in environments that have little tolerance for failure.

Rather than reasoning by anecdote, it might be helpful if participants 
in this conversation cited verifiable and peer-reviewed evidence.

Henning

---

From: Bill Woodcock <[email-masked]>
Date: Sat, 9 Nov 2002 09:14:38 -0800 (PST)

On Sat, 9 Nov 2002, Henning Schulzrinne wrote:
    > in the global scheme of things, with O(100) nodes.

That's nice.  Show me a larger inter-carrier production VoIP network, and
you'll be well on your way to being taken seriously.

    > All available evidence...
      ^^^^^^^^^^^^^^^^^^^^^^

You appear to have misspelled "three armchair theoreticians."

    > ...indicates...

"speculate"

    > (see Infocom 2002 paper "Assessment of VoIP quality over Internet
    > Backbones" [http://www.ieee-infocom.org/2002/papers/355.pdf]

Did you even read that paper?  They didn't measure anything, and they
didn't try any VoIP.  Nor did they assess VoIP, quality, or the
Internet. How could it possibly be relevant to anything? All they did was
re-publish a _vendor's_ claims about observed network behavior without
verification or review.

    > papers by Maxemchuk and Lo in ICC 1997

...at about which time, dinosaurs roamed the earth...

    > and any number of "Internet weather" sites)

...you've GOT to be joking.

    > in this conversation cited verifiable and peer-reviewed evidence.

Quite the opposite.  Rather than presenting circular chains of mutual
citations between equally uninformed academics, it might be helpful if a
few other participants in this conversation DID SOME VERIFICATION.  Since
Peter and I are the only ones who have, so far, a few of the rest of you
might spend a little bit of your excess time getting started on that.

                                -Bill

---

From: Bill Woodcock <[email-masked]>
Date: Sat, 9 Nov 2002 09:38:00 -0800 (PST)

Oh, and another thing:

    > in the global scheme of things, with O(100) nodes.

Aside from being personally insulting, since I have to assume you're
capable of running wc -l and typing the number of zeros you intend to
type, I can only conclude that you're attempting to intentionally mislead
participants in the working group.  Neither of which are reasonable
behavior.

                                -Bill

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 09 Nov 2002 13:32:54 -0500

My numbers come from 
http://www.pch.net/about/news/pressreleases/pressrelease10.28.02.html, 
where 120 and 150 are mentioned. I'm sorry if I read the wrong press 
release.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 09 Nov 2002 13:48:38 -0500

>     > All available evidence...

I look forward to citations of peer-reviewed data that contradicts these 
assessments.

> You appear to have misspelled "three armchair theoreticians."

Your ad-hominem arguments are not particularly helpful.

> re-publish a _vendor's_ claims about observed network behavior without

The authors are presumably not on this mailing list to defend 
themselves. Section IV.A describes the analysis of data performed by the 
authors. What concrete indications do you have that the measurement data 
is incorrect, unreliable or otherwise untrustworthy?

The data pattern does represent at least one reasonable representation 
of VoIP traffic.

> ...at about which time, dinosaurs roamed the earth...

As mentioned, I would value pointers to published evidence that 
contradicts their conclusion. The evidence that I have (cited in the 
references of the paper mentioned, for example) is all fairly 
consistent, indicating that the changes in observed performance over the 
5-year horizon have been marginal.

> might spend a little bit of your excess time getting started on that.

We are indeed looking for places to put measurement probes right now and 
would be grateful for sites willing to host our test software. We're 
interested in sites beyond the usual academic network sites, so sites on 
your network would be particularly helpful.

---

From: Bill Woodcock <[email-masked]>
Date: Sat, 9 Nov 2002 10:43:37 -0800 (PST)

> lot of continuing aggravation.

To reiterate, for the Nth time:

The Internet provides high probability of call completion in telephone
(IP) systems.

    > The first is whether the network can provide priority transport
    > The second is whether telephony elements are informed that a
    > particular call is an emergency call

Neither of which have anything to do with your stated requirement.

                                -Bill

---

From: Ken Carlberg <[email-masked]>
Date: Sat, 09 Nov 2002 18:50:10 +0000

> ieprep indication in terms of avoiding overload.

just a thought to consider.  there are voip systems in enterprise nets
that switch calls to the PSTN if the internal data net cannot support
PSTN toll-quality for the call(s).  my understanding is that some of
these systems essentially use counts as a rough estimate of load for
segmented traffic.  i wouldn't recommend this approach with SIP, but 
I wouldn't discount someone from doing this at some point either.

> ieprep services which users will reliability have with tem when they need

actually, I would postulate that once the contracted measure of 'loosened'
admission control is reached (be it through valid users or DoS attack),
users that attempt labeled emergency calls gets the same service as the
common (non-labeled) user.

> what is already in Hennings SIP requirements document

even with what I said above, i agree.

-ken

---

From: Bill Woodcock <[email-masked]>
Date: Sat, 9 Nov 2002 10:46:17 -0800 (PST)

On Fri, 8 Nov 2002, Gary Thom wrote:
    > non-normal conditions.  In this situation, we want to give emergency

What possible greater advantage could they have than travelling the
best-supported path?  Why would you want to disadvantage them by making
them travel a path which was QoS-dependent, and would thus fail all the
time?

                                -Bill

---

From: RJ Atkinson <[email-masked]>
Date: Sat, 9 Nov 2002 14:09:20 -0500

On Saturday, Nov 9, 2002, at 11:50 America/Montreal, Henning 
Schulzrinne wrote:
> By simple logic, no vocoder, however evolved, can cover losses that 
> are long enough to delete significant portions of a syllable or word, 
> unless you're willing to tolerate delays that turn interactive voice 
> communications into voice messaging.

No question.  That agreed to, there are vocoders that are more tolerant
of adverse network conditions and vocoders that are less tolerant of
adverse network conditions.  One will tend to be more successful over IP
with the former than with the latter.

> All available evidence indicates (see Infocom 2002 paper "Assessment 
> of VoIP quality over Internet Backbones" 

I'm not terribly impressed by a lot of the published papers on Internet 
measurement
-- simply because in many cases the measurement did not use enough 
controls to
understand what was really being measured.  There is some work by folks 
at ICIR
on how hard it really is to measure stuff accurately, for example.

And many of the "Internet weather" sites don't bother trying to have 
good controls,
hence yield uninterpretable graphs.  If you have a specific good such 
site in mind,
please share it with us.

That noted, It would be pleasant if we could talk about the merits (or 
lack of them)
for specific papers.  Is that the main paper you suggest looking at, or 
did
you want to suggest a broader set for this discussion (URLs 
particularly welcomed) ??

And I'd definitely not be so bold as to claim "All available 
evidence..."
as you did.  At a minimum, the evidence is mixed.

Thanks,

Ran

---

From: Scott Bradner <[email-masked]>
Date: Sat, 9 Nov 2002 14:11:14 -0500 (EST)

> I wouldn't discount someone from doing this at some point either.

note that SIP servers & proxies do not deal with the data stream, they just
deal with signaling so I do not know how this would work with SIP 

Scott

---

From: RJ Atkinson <[email-masked]>
Date: Sat, 9 Nov 2002 14:12:10 -0500

{Aside: 	I fixed the subject to be more accurate.  We should
be doing that more often, IMHO. :-}

On Saturday, Nov 9, 2002, at 12:14 America/Montreal, Bill Woodcock 
wrote:
>  it might be helpful if a

Bill,

	You at least owe us a URL or bibliographic citation to your own work
if you are using it as your justification.  Henning was good enough to
provide a specific URL and bibliographic citation, which helped focus
things a great deal.

	Maybe you could find some presentations from NANOG, RIPE, or APRICOT
that are online and relevant to the discussion ?

Thanks,

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Sat, 9 Nov 2002 14:18:49 -0500

> I wouldn't discount someone from doing this at some point either.

That is roughly congruent with what I hear about VoIP in Enterprise 
LANs.
I'll also note that my (non-scientific) sample of VoIP use in Enterprise
LANs leads me to believe that many such deployments deliberately put
the IP phones on dedicated Ethernet segments (for whichever reason;
could well be administrative convenience).

Ran

---

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

On Sat, 9 Nov 2002, Henning Schulzrinne wrote:
    > Section IV.A describes the analysis of data performed by the authors.

Yes.  They created a theoretical model, applied it to someone else's
completely unrelated and unverified data, didn't verify that their
results had anything to do with reality, and published it.

That would seem to me to put them deep in the cusions of armchair
theoreticality.

    > What concrete indications do you have that the measurement data

No reason to think that the measurement data was faulty.  It wasn't
collected with VoIP in mind, of course, but it might be generally
applicable enough to be useful.  Of course one has no way of knowing,
since it's simply one vendor's information which is presumably
principally being used in support of sales of their product.

The issue is that the model, when applied to the data, produced a result
which contradicts observed reality.  But since the authors didn't bother
to observe reality, they didn't notice this.  Since you're citing them
rather than observing reality, and urging other people to ignore reality
in favor of circular chains of unverified mutually-citing papers, I have a
hard time figuring out what you're getting at.

    > your network would be particularly helpful.

You're quite welcome to go ahead and ask them.  And if there's any
chance at all that your measurements will get people to stop
asking for things they don't want, I'm all in favor of it.  However, I'd
guess that since networks are run by operators, they'll probably ask you
whether there's some problem you're trying to solve before they dedicate
any resources to your project.  So you probably want to think about how
you're going to answer that.

Wouldn't it be a lot more direct to just use the phones, rather than
"measurement probes" and "test software?"

                                -Bill

---

From: Bill Woodcock <[email-masked]>
Date: Sat, 9 Nov 2002 11:23:04 -0800 (PST)

> that are online and relevant to the discussion ?

The slide-set from NANOG is at:

http://www.pch.net/inoc-dba/INOC-DBA-announcement.htm

Slide 9 has a chart with calls-per-day in yellow and number of phones in
use in red.  Of course, they're out-of-date now, since we're into
November.

Slide 8 is PAF's nephew, setting up his phone.  Which worked fine, by the
way.  :-)

                                -Bill

---

From: Bill Woodcock <[email-masked]>
Date: Sat, 9 Nov 2002 11:24:45 -0800 (PST)

> could well be administrative convenience).

The PoE switch ports are really expensive, so you don't want to waste them
on things other than phones and WAPs.

Also, DHCP options can be pretty different for phones than for other
things.

Those are the two main reasons.

                                -Bill

---

From: Bill Woodcock <[email-masked]>
Date: Sat, 9 Nov 2002 11:27:06 -0800 (PST)

> in the global scheme of things, with O(100) nodes.

My apologies.  Henning informs me that I should have interpreted 0(100) as
meaning the range 50-499, which should still be accurate for another three
weeks or so.

                                -Bill

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 09 Nov 2002 14:31:09 -0500

> with the former than with the latter.

I don't think there's any disagreement about this. Indeed, certain 
companies mentioned in one of our papers strive to add robustness to 
standard codecs like G.711. Generally speaking, codec design is a 
trade-off between robustness to packet loss, quality and robustness to 
other impairments and a host of competing objectives (robustness to 
multiple talkers, background noise, available CPU resources in 
large-scale gateways, tandeming performance, ability to deal with DTMF, 
etc.).

> for specific papers.  Is that the main paper you suggest looking at, or did
> you want to suggest a broader set for this discussion (URLs particularly 
> welcomed) ??

The papers cited in the Infocom 2002 paper are a good beginning. 
Unfortunately, due to copyright reasons, you may need to be a subscriber 
to the ACM Digital Library or IEEE Xplore to obtain some of the papers. 
Not much I can do about that.

> 
> And I'd definitely not be so bold as to claim "All available evidence..."

I should have said "all published evidence that I have seen". As I've 
said a few times, I would be sincerely interested in quantitative 
evidence to the contrary.

All measurements are limited and, indeed, are getting to be increasingly 
difficult to make for a variety of practical reasons; I don't think 
falling back to "it works for me" arguments is a suitable replacement 
for measurements, however limited. Also, in some sense, it is sufficient 
to show that reasonable measurements found problems, not that all 
networks have problems all the time. We're not talking about average 
performance here, but rather the tail of the distribution. We can argue 
about whether we care about the 99th or 99.9th or whatever percentile. 
Since most measurements are, by their nature, short, even a single 
observed problem will likely put usability beyond many reasonable 
reliability requirements.

Since we may have different expectations, it might be helpful to get 
feedback on what people would consider reasonable reliability. Is it ok 
if 1% of calls fail (where "fail" may mean "sufficient disruption to 
cause users to abandon the call")? 0.1%? Even lower?

(As a side note, I suspect that plain reachability problems contribute 
the vast majority of "QoS" problems, something that DiffServ and kin are 
unlikely to fix. See the papers by Labovitz et al. on observed Internet 
reliability [e.g., UMich TR 382-98])

---

From: Scott Bradner <[email-masked]>
Date: Sat, 9 Nov 2002 14:34:48 -0500 (EST)

> I should have interpreted 0(100) as
> meaning the range 50-499,

crypto?

:-)

Scott

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 09 Nov 2002 14:45:45 -0500

> ieprep indication in terms of avoiding overload.

This has been discussed a few times, but may be based on a somewhat 
limited view of what SIP proxies can do. I think a fair comparison is 
that a SIP proxy is in many ways similar to a web or email server. In 
particular, SIP proxies do execute per-call user code (sip-cgi, 
servlets, CPL, etc.), which can put a significant burden on any CPU. 
Also, a SIP proxy may need to consult an external database for call 
filtering (check for callee in "known telemarketers list") or AAA reasons.

Just like news web servers switched to static, non-image pages after 
9/11 to deal with the flash crowds, SIP servers may well decide to 
change their operating characteristics under call handling overload. 
This could involve no longer invoking CPU-intensive per-call processing 
tasks or reserving a certain request handling capacity to high-value 
calls. This is very similar to the remarks you made about networks 
earlier in your message, i.e., simple, absolute and unconstrained 
priority may not be sufficient.

Most of this can be done locally and without protocol support; in some 
cases, SIP signaling information may provide additional useful input 
into such algorithms.

In general, it might be helpful to differentiate (1) behavior that can 
be done locally based on already available information, (2) can use 
additional mechanisms to improve performance, and (3) absolutely needs 
additional protocol indications to make any sense.

> ieprep services which users will reliability have with tem when they need

There might be a wrinkle here that differentiates this from normal 
operation. For example, given other constraints, I may not care that 
somebody can break a key by one week computational brute force, since 
the emergency is likely to last much shorter than that.

---

From: RJ Atkinson <[email-masked]>
Date: Sat, 9 Nov 2002 15:04:46 -0500

On Saturday, Nov 9, 2002, at 14:23 America/Montreal, Bill Woodcock 
> The slide-set from NANOG is at:

That helps with regards to the phones.

Are there other more generic presentations on congestion (or lack of it)
in real production networks that have been presented at ARIN/NANOG/RIPE
recently ?  Is there data that CAIDA has that is public enough to be
useful ?

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Sat, 9 Nov 2002 15:06:36 -0500

On Saturday, Nov 9, 2002, at 14:31 America/Montreal, Henning 
Schulzrinne wrote:
> the vast majority of "QoS" problems, something that DiffServ and kin 
> are unlikely to fix. See the papers by Labovitz et al. on observed 
> Internet reliability [e.g., UMich TR 382-98])

This would not surprise me a bit.  And I suspect Bill will also agree 
with this.

Ran

---

From: Bill Woodcock <[email-masked]>
Date: Sat, 9 Nov 2002 12:14:54 -0800 (PST)

> This would not surprise me a bit.  And I suspect Bill will also agree

Yes, agreed.  In general, what I and most other operators I know observed
while running QoS on production networks, was that it didn't help
anything, since there generally either existed an uncongested path, or no
path.  In the extrordinarily rare cases when congestion exists, it
typically exists because of some definite, temporary, intentional reason,
and QoS wouldn't change typical reasons.

QoS isn't a hammer you can use to force packets you think are important
through someone else's network.

                                -Bill

---

From: Scott Bradner <[email-masked]>
Date: Sat, 9 Nov 2002 15:26:04 -0500 (EST)

> reliability requirements.

I'd change "usability" to "recorded usability" - i.e., an observed 
problem on a short measurement my not be easily able to be translated into
what it actually would mean to VoIP users on the net - would the disruption
hit many of the users, would it hit for long enough to be a problem (i.e.
the hang up phone level)

not - not all tests are short or show major issues see
http://www.nanog.org/mtg-0105/casner.html

these tests were about a week long and at a reasonable speed
and they showed few problems - mostly rerouting timeouts

yes they were just within an ISP an did not deal with
tail circuits but even so can say someting about the base reliability
of some ISP backbones

VoIP users in this environment would see a few 300 sec or so outages a week
if they were quite unlucky to be calling when there was a routing funny

Scott

---

From: RJ Atkinson <[email-masked]>
Date: Sat, 9 Nov 2002 16:11:33 -0500

On Saturday, Nov 9, 2002, at 15:14 America/Montreal, Bill Woodcock 
> and QoS wouldn't change typical reasons.

	Maybe it would be informative if you outlined some examples of why
congestion might exist for a "definite, temporary, intentional reason".
Those might be obvious to you, but not necessarily as obvious to 
everyone.

Ran

---

From: Bill Woodcock <[email-masked]>
Date: Sun, 10 Nov 2002 03:57:17 -0800 (PST)

> congestion might exist for a "definite, temporary, intentional reason".

- User site might be undergoing some sort of move or transition in which
temporary bottlenecks (temporary L2 bridge between old site and new site)
appear, across which things like routing packets and SMTP/IMAP need to
flow, but nothing else is deemed particularly important.

- User site might be hosting a webcast, and might want all available
bandwidth to go to a large number of fixed-size streams, with no bursty
interruptions.

- User site might be going bankrupt, and decrease tail-circuit size to
preserve cash.

- User site might be using aggregated dial-on-demand channels (ISDN,
satcom, et cetera) for their tail-circuit, and have very specific ideas
about what types of traffic may validly trigger the addition of channels.

                                -Bill

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 10 Nov 2002 10:32:28 -0500

At least from my local operational experience, the three most common 
reasons for excessive losses and delays are:
(1) failure of one of our outbound circuits or router interfaces 
(Columbia has a "commodity" Internet connection and an Internet2 
connection, with automatic failover from I2 to "commodity", each OC-3)
(2) severe congestion on the peering link between Sprint (upstream 
provider of Applied Theory, the [prior-to-Chapter-7/11] ISP for 
Columbia) and AT&T;
(3) denial of service attack, either inbound or outbound.

Recently, (3) has been the most common, followed by (2) and one incident 
of (1).

I have the traces and mail to our NOC for examples for each :-)

RJ Atkinson wrote:
> 
> On Saturday, Nov 9, 2002, at 15:14 America/Montreal, Bill Woodcock wrote:
> 
> Those might be obvious to you, but not necessarily as obvious to everyone.
> 
> Ran
>