Subject: RE: [Ieprep] requirements document(s)

From: "King, Kimberly S." <[email-masked]>
Date: Wed, 18 Sep 2002 09:56:44 -0400

> 4. The proceeding shows only minutes of the interim
> meeting. Hence, I dont know what the group is
> currently focusing on..esp sipping/ieprep interactions.

Try http://www.ietf.org/proceedings/02jul/index.html for information on the
Yokohama meeting.

> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! News - Today's headlines
> http://news.yahoo.com
> _______________________________________________
> 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: "King, Kimberly S." <[email-masked]>
Date: Thu, 19 Sep 2002 07:45:43 -0400

[MAP] 2) It is unknown how to interpret the statement that "labels for
different layers are NOT required to be related to each other". The
fundamental requirement detailed in draft-pierce-sipping-assured-service-02
presumes that the "label" which identifies the call level priority will be
mapped into a "label" which identifies the packet layer priority or
preferential treatment class. This statement seems to explicitly say this is
not required. 

[KSK]  Saying something is NOT required is not equivalent to saying it is
forbidden.  

[MAP] 3) It is unknown what the statement that "Policy MUST be kept separate
from the label(s)" means as a requirement. Unfortunately, this issue
(policy) has caused much disagreement in the past, and this hard statement
could be interpreted by various people to defend various positions. The real
meaning of this needs to be expressed without assuming that everyone has the
same concept of what "policy" means or what a "label" is in this context. 

[KSK] Suggest the the terms label and policy are defined in the document
since there multiple possible meanings.

[MAP] 1) Accounting should be moved to "Requirements". It is a fundamental
requirement as detailed in draft-pierce-sipping-assured-service-02. 

2) Admission Control - In a congested network, admission controls to prevent
new low priority calls from being setup is a requirement. 

[KSK]  First, please consider that requirements, if this document is to
someday represent requirements for ieprep, should come from a working group
consensus not because they appear in
draft-pierce-sipping-assured-service-02.

Also, note there is a potential problem here.  If you want the document to
reflect the "the efforts MUST take into account the existence of regulations
in various countries with which carriers will have to comply. " then you
can't require prevention of low priority calls being setup during
congestion.  One way to think of the admission control issue is that this
draft leaves the possibility for the type of admission control you describe
without mandating it.

---

From: "King, Kimberly S." <[email-masked]>
Date: Thu, 19 Sep 2002 08:00:26 -0400

> >What I disagree on is that I believe we need some kind of 
> standards-defined
> >interface between Layers 3 and 2.  (Phil Neumiller and I 
> have had some of 
> >this discussion in the MANET list on what Phil calls the 'soft 
> underbelly'.)
> >
> >There are one-off solutions here -- multicast IP traffic is 
> recognized by 
> >ethernet switches equipped with IEEE 802.1p and then 
> multicast over the  
> >switch's fanout.  What we need is a generalization of what 
> you might call 
> an
> >API that allows these IP functions to be reflected in the 
> data link layer:
> >	- QoS labels (e.g. DSCP)
> >	- IP multicasting
> 
> ok, understood.  within the current charter of IEPREP, its realization
> would need to be in the form of a requirement.  
> 
> its something that will probably require additional thought.  
> however, my 
> initial impression is that making a requirement for an API is 
> a bit odd.  
> the effort probably needs to be done in a different working group, or 
> require a charter of IEPREP (which is probably premature at 
> this stage).  
> 

Not that this isn't interesting, but we need to focus the efforts at the
present time to the SIP requirements document.  
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: "King, Kimberly S." <[email-masked]>
Date: Fri, 20 Sep 2002 14:22:12 -0400

[MAP] I guess I'm confused by this issue of Admission Control. Even without
something called "IEPREP" or "Assured Service", isn't Admission Control
required? If a network or path is already congested, don't new calls have to
be "prevented"? The circuit-switched world had it easy - when it ran out of
circuits, it blocked new calls. Where is the equivalent function in IP.
Isn't it called "Admission Control"? 

 First, in general, IP networks do not come with "admission control".  Most
IP traffic (applications like email, file transfers, etc.) uses a protocol
called TCP that adjusts its sending rate according to network conditions
(and some other things).   It's only view of the network and congestion
along the path comes from latency and drops that it experiences for traffic
that it sent out.  It sends some traffic, if it gets to the receiver okay,
that side says "got it" and so the sender assumes things aren't congested
and tries to send a little faster.  If some stuff gets dropped, the other
side complains, and the sender will slow down it's sending rate since it
assumes it must be congested somewhere.  It also resends the missing stuff.
 
Other types of traffic (like voice media packets and a lot of SIP signaling)
use another protocol called UDP.   We can't play the nice TCP game here
because the voice packets need to be delivered as smoothly as possible and
we don't have time to resend things that get dropped because of delay
requirements.
 
Now, let's examine a general SIP server...it has no idea whether the network
is congested or along what paths.  It, along with several other SIP servers,
participates in setting up calls (say between two entities A and B).  The
SIP servers aren't necessarily lying along the paths eventually to be taken
by voice packets between A and B.  That's part of why SIP servers can't
affect the QoS for the voice streams.  The other interesting thing is that
on a general IP network, there is no entity that keeps track of where
congestion is and when new connections shouldn't be setup.  
 
I'm not saying there aren't some special tools you might deploy on a
priviate network to try to track things like this and you could try to get
your vendor to support some policy-based networking tools.  I'm only saying
this is how it generally works and there is no general admission control.
 
The separation of labels and policy is an important issue and the use of
DiffServ needs some investigation.  Certain applications have requirements
that have to be balanced somehow with mission importance.  For example, if
one where to place all priority email, file transfers and voice packets in a
priority queue while placing routine email, file transfer and voice packets
in another queue, one might get some very, very bad service for lots of
traffic including priority ones.  [For example, think about the jitter
introduced in having those tiny voice packets mixing with possibly large
packets from file transfers.]  It is possible to create some real problems
but there are reasonable ways to deal with these issues.  Network modeling
and pilot programs might be a good approach before trying to standardize
things.  The results are sure to be surprising!  This is also related to why
this working group shouldn't try to come up with "solutions" but rather
focus on "requirements".  Otherwise, the temptation to apply the same ole
techniques in a new environment where these techniques no longer apply
directly just isn't a good idea.  So, back to requirements...
 
In this working group, we are examining a different stage.  In a way, you
have to think backwards.  Think about what you would need for Assured
Service and remove the policy (i.e., the interpretation of how you will
allocate resources for traffic with various labels).  You can add the policy
later in your own network.  Here's the document
http://www.ietf.org/internet-drafts/draft-ietf-ieprep-sip-reqs-00.txt
<http://www.ietf.org/internet-drafts/draft-ietf-ieprep-sip-reqs-00.txt>
that we need to focus on now.  In it, you will find potential requirements.
Are these requirements sufficient so that when you add your own policy, you
can achieve the signaling aspects necessary for Assured Service?  Is there
anything else you need?  Are there things that would be nice to have but
simply aren't absolutely necessary?  All of my statements apply in general
for any ETS scheme.

---

From: [email-masked]
Date: Mon, 23 Sep 2002 16:42:46 EDT

In a message dated 9/20/2002 4:57:47 PM Eastern Standard Time, 
[email-masked] writes:

> Mike,  I think you're disagreeing with the hints I dropped about how to go 
> about preventing precedence creep.  But we seem to be agreeing that _some_ 
> means of controlling precedence creep is necessary.  Therefore, at 
> requirements time, we simply state that.  (either crib the second sentence 
> in 
> this paragraph or the 3rd bullet below -- and drop the modifier 
> 'authentication'.
> 

No, absolutely I do not agree. There is nothing that we, or the protocol can 
do to prevent precedence creep. It is out of scope.

The only thing related to this is that accounting (keeping records of use of 
precedence) is required.

Mike Pierce
Artel

---

From: "King, Kimberly S." <[email-masked]>
Date: Tue, 24 Sep 2002 08:18:48 -0400

We've touched on a conglomeration of ideas here including packet level
priority, call level priority, issues of policy (i.e., resource allocation
for traffic with various labels) and what happens when policy is abused
(i.e., "precedence creep").  Some of this is design specific and so a bit
out of scope.

I believe an original issue was whether accounting must be a general ieprep
requirement.  It appears that it may occur (and is listed as an issue) but
isn't a general ieprep requirement; however, if this item is critical for
assured service (sometimes called MLPP) then perhaps a more specific MLPP
requirements draft should cover this. 

Question 1: Can we assume the above is acceptable and consider the
accounting issue for the general ieprep requirement closed?

If I am reading the concerns with accounting, the comments appear to be
focused on not on general ieprep requirements but with respect to IP
telephony.  It appears the underlying reason some seek it is to determine
after the fact who has used the service and at what priority.  This
essentially asks for a "call detail record" CDR with priority info included.

Question 2: Is a CDR an ieprep IP Telephony requirement or is this an MLPP
specific requirement? 

Question 2a: Is a CDR only a reasonable requirement when interacting with
CSN gateways?

Kimberly

-----Original Message-----
From: senthil ayyasamy
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Sent: 9/23/2002 11:05 PM
Subject: Re: [Ieprep] requirements document(s)

--- [email-masked] wrote:
> In a message dated 9/23/2002 9:10:49 PM Eastern
> Standard Time, 
> [email-masked] writes:
> 
> 
> > It seems to be that you are suggesting
> *accounting*
> > as a means for carrying out  authetication
> function.
> > So, authetication is still a requirement.
> > Though the question is out of scope for the 
> > requirement draft, How do you do accounting of
> Labels
> > ? RADIUS or something. Is their any standard
> practised
> > method? 
> > 
> 
> I really don't know what your question is.
> Accounting is the function of 
> keeping records of the use of a service, whether a
> count of the times or the 
> total duration of calls at each priority level. No,
> this is not a means to 
> carry out the authentication function. 
you have answered my doubt. But, at times, i really
get bugled by the whole discussion. we start with
packet-level priority and end up assuming call-level. 

>Yes, the
> records can be looked after 
> the fact to check up on the authentication function,
> or to look for 
> "precedence creep", i.e., misuse of priority levels.
> But it's not something 
> that we need to worry about. 

__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com
_______________________________________________
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: [email-masked]
Date: Thu, 26 Sep 2002 09:29:46 EDT

> (i.e., "precedence creep").  Some of this is design specific and so a bit

[MAP] I've been trying to get the issues of call level priority and packet 
level priority discussed separately for a long time. Often, a discussion of 
one drifts off to the other.

I don't refer to packet level "priority", since the word "priority" implies a 
specific procedure. I refer to "preferential treatment", since other 
techniques besides "priority" may be applicable. Some are described in 
draft-pierce-sipping-pref-treat-examples which I will resubmit to IEPREP 
soon. I would appreciate comments on it.

> assured service (sometimes called MLPP) then perhaps a more specific MLPP

[MAP} The requirement for Accounting was included in 
draft-pierce-sipping-assured-service-02. If more needs to be said, I could 
add it. Any ideas?

I feel quite certain the accounting is a basic requirement of GETS today. 
Surely the government's contract with service providers requires them to be 
able to record evidence of the use of the service, both the number of total 
uses as well as detail about each use.

> Question 2: Is a CDR an ieprep IP Telephony requirement or is this an MLPP

[MAP] The requirement listed in draft-pierce-sipping-assured-service was for 
what you called a "Call detail record". I used the term "accounting", maybe 
erroneously. Guess we need to be careful with this word, since some assume 
(maybe correctly) that "accounting" only relates to collection of money.

Yes, I believe the ability to do CDR is a requirement for both. If a service 
provider elects to turn it off, fine. I understand a "requirement" in a 
document as meaning that a compliant piece of equipment must have the 
capability, not that the user of the equipment must use the capability.

> Question 2a: Is a CDR only a reasonable requirement when interacting with

[MAP] Whether or not CDR (or accounting) is required should be independent 
from the architecture, such as whether interacting with CSN gateways.

Mike Pierce
Artel