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

From: Daniel Sullivan <[email-masked]>
Date: Tue, 05 Nov 2002 14:13:49 -0500

I think this group is working on stuff for the future. If we didn't need to
make changes, we could shut down the IETF.  How boring that would be! :-))

Steve Silverman   who can't read his email because his computer died.

RJ Atkinson <[email-masked]> wrote:

I don't want to have any requirements that can't be met
(with currently visible technology).  I think this is
just that.  If you think that it can be met, please explain how.

Thanks,

Ran
[email-masked]

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

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

---

From: "Nguyen, An" <[email-masked]>
Date: Fri, 8 Nov 2002 12:21:40 -0500

Gary,

I totally agree with you on this ...

An

Also, realize that Hal's work is not specifically DoD centric, but will
be
used to support federal, state and local emergency management personnel,
police, fire and medical personnel who are trying to communicate in
emergency situations.

Speaking for MYSELF, if the world begins to use IP transport for public
telephony, I (personnally) think it would be important to support
priority
access to the system for emergency communications. That way, when the
Ivory
Tower begins to crumble, emergency personnel can coordinate rescue
efforts
inspite of our continuing waste of bandwidth on this circular,
sandbagging
trivia.

Gary Thom
Speaking on behalf of and for myself.

 --------------------------------------------
 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
--------------------------------------------
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: "King, Kimberly S." <[email-masked]>
Date: Sun, 10 Nov 2002 06:37:10 -0500

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

>crypto?

I don't know, could be Big-O notation.

Maybe if f(n) is the number of users at time n then the assertion is there
are positive numbers c and N such that for all n >= N then

f(n) <= c*100.

Some people might consider this crypto. :-)

Kimberly

---

From: [email-masked]
Date: Tue, 12 Nov 2002 15:55:11 EST

In a message dated 11/11/2002 11:34:14 PM Eastern Standard Time, 
[email-masked] writes:

> > a permissible call defect rate of 0.00001%
> 
> 1/ I've not heard of an FCC requirement but maybe 
> 
> 2/ what is a defect - in the context of the Internet?
>     I would doubt that it is a dropped packet
> 

[MAP] This relates to my comment yesterday about (draft) ITU-T Y.1530 which 
defines a number of "call defects" for voice over IP. I suggest that 
reference be made to that draft for formal definitions of end-to-end 
performance, including "defects". Then this group can carry on easier 
discussions of what the numbers should be for various situations. I'm sure we 
can get the okay to make a copy of the latest draft (from last week) 
available.

Briefly, Y.1530 (draft) defines:

Connection Setup Delay
Connection Post-Selection Delay
Connection Answer Signal Delay
Connection Disconnect Delay
Connection Release Delay
Connection Set-up Error Probability
Connection Set-up Failure Probability
Connection Premature Disconnect Probability
Connection Clearing Failure Probability

Although ITU-T in the past dealt with circuit switched, the end-to-end 
performance parameters defined in this draft have been modified to apply to 
packet technology. If anything, the use of IP introduces the need for 
additional parameters, since it introduces additional degradations of 
quality. One thing that is missing seems to be the notion that a call can be 
successfully set up, the party answers, and then there is no media path 
available. (Didn't happen in the circuit switched world.) This is what 
Henning commented about on Nov 11 with:

- Call rings, callee picks up and then there's no conversation (due to 
failure of local resource reservation; this is the problem the 
PacketCable folks worried about since they need to manage the very 
limited upstream bandwidth)

Separately, Y.1541 covers transmission parameters of:

Packet Transfer Delay
Packet Delay Variation
Packet Loss Ratio
Packet Error Ratio

I suppose that the case Henning mentioned could simply be thought of as 
Packet loss ratio = 100%.

Mike Pierce
Artel