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

From: [email-masked]
Date: Fri, 20 Sep 2002 10:06:28 EDT

In a message dated 9/19/2002 10:06:34 AM Eastern Standard Time, 
[email-masked] writes:

> 
> 
> > 2.1 The statement that "adhering to regulations and laws of governments
> > is out of scope" seems a little strong and could be misleading, causing
> > some to think that the IETF is going to ignore the presence of existing 
> > regulations and produce something that can not be legally used in many 
> > countries. This needs to be rewritten to recognize that there are
> > government laws which carriers must comply with and that this work in
> > the IETF will attempt to provide the framework for that compliance. I
> > suggest the following rewrite of this sentence: 
> >
> > Further, the specification of requirements to address specific regulations
> > or laws of governments is also out of scope of this document, however,
> > the efforts MUST take into account the existence of regulations in
> > various countries with which carriers will have to comply. 
> 
> [KC] taken literally, your above suggested change with the use of "MUST"
> means that people are going to have to be familiar with regulations
> of 160(?) countries and anywhere between 10-50(?) times that number of
> legal jurisdictions.  thats not the path to travel.  
> 
> so i'll gladly be corrected by the chairs, ADs, or any of the other
> powers that be, but the bulk of the working groups of the IETF only
> focus on technical standards.  i don't recall any RFC from a working 
> group that said, "because of regulation X, do Z".  nor do i recall
> any working group charter that mentions country laws and regulations.
> the only exceptions I can think of are ones that deal with the IETF
> process (eg, POISON).
> 
> 

[MAP] I see your point. I just think we need to word it so it doesn't come 
across as saying "We' don't care about any laws anywhere and will 
intentionally ignore them" (because that's the impression I've gotten from 
some participants in other discussions). How about "... the eforts should 
consider the possible impact of regulations in various countries with which 
carriers will have to comply"?

> 
> > 4. Issues 
> >
> > 1) Accounting should be moved to "Requirements". It is a fundamental 
> > requirement as detailed in draft-pierce-sipping-assured-service-02. 
> 
> [KC] however, the pierce draft is not representative of all IP telephony.
> accounting generally is associated with billing.  there may be an
> organization that chooses a flat-rate fee type SLA.  given an 
> accompanying authentication/integrity service, they may choose not
> to use accounting.  hence, i don't see a need to *require* them to
> use have a separate accounting mechanism.
> 
> if the group decides the follow the separate requirements model we have 
> proposed, then it may be better to migrate the pierce draft into one that 
> lists additional requirements for MLPP
> 

[MAP] I don't see this draft as addressing "all IP telephony". Since it 
addresses the specific application of IEPREP, I believe accounting is a 
requirement. Accounting does not only mean "billing". In this case, it means 
keeping records of the use of the service for traffic studies and fraud 
detection. The service depends on the ability to do these two functions.

I suppose there is a difference of idea of what it means to list a 
"requirement". I see it as meaning that the capability must be provided (in 
the draft standard), not that every situation must do it.

> > 2) Admission Control - In a congested network, admission controls to
> > prevent new low priority calls from being setup is a requirement. 
> 
> [KC] if I'm a tier-1 provider, and my customer is satisfied with an SLA
> that simply segments labeled traffic into a different virtual path and 
> over-provisioning is the method contracted to achieve a high
> probability of forwarding the traffic through the network, then that
> provider shouldn't be required to support an Admission Control mechanism.
> 
> this follows the theme of the document in that we make no assumptions
> about the labels or what is to be done with them.  in the above, you use
> the term "prevent".  what if I choose the term "reduce the probability"?
> which term would be used as a requirement?
> 
> again, perhaps its best to have a subsequent MLPP draft that offers more
> 

[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"?

> 
>          =================================================
> 
> > draft-carlberg-ets-telephony-00 
> > 
> 
> > 2.1 This section, as written, should not be necessary. It must be
> > generally understood that all documents produced by the IETF share this 
> > situation - they do not, by themselves mandate any carrier to follow
> > them. The over-emphasis on the point here might make somone wonder. 
> 
> [KC] i agree that the section should not have to be stated, but 
> unfortunately,
> your assumption is not correct.  there are non-technical people who do
> not understand that IETF documents do not represent mandates to carriers.  
> and i've been rudely given the riot act about this from technical 
> people.  

[MAP] I agree that people need to be reminded of this, but I found this 
statement in the body of the document a little strange, and strong. I don't 
recall generally seeing a similar statement in other drafts or RFCs. As is 
done in American National Standards (and I imagine other standards) there 
should maybe be a standard statement in the beginning of all standards track 
documents to remind people of this. (This should be considered along with a 
general modification of the standard format for RFCs, but, then, I suspect 
that will never happen.)

Mike Pierce
Artel

---

From: Rex Buddenberg <[email-masked]>
Date: Fri, 20 Sep 2002 09:58:10 -0700

> 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"?
>
>

Mike,

Packet switching characteristics under load are different ... and more 
granular, than circuit switching.  

When a circuit switched comms system is congested, this translates 
one-for-one in 'there aren't enough circuits to go around' and a remedy is to 
simply not honor some requests for circuits (i.e. make the dial tone go away, 
busy signal, ...)

When an internet structure is congested, it is almost always characterized by 
router queues overflowing, meaning some packets are getting thrown away.  
This congestion usually occurs at the interior of the network, not at the 
border routers.  So throttling input requires backpressure messages that go 
through at least one router back to n origins ... it quickly adds up to 
plugging more holes in the dike than you have fingers for.  And it requires 
that you the network manager have at least some control over my desktop (or 
laptop or PDA) which aside from being allergically intrusive is Real Hard to 
do.  Besides, if the traffic is local (doesn't reach the congestion point), 
there's no gain to turning it off.  (The old paper-based military messaging 
system was full of these events).  

The mechanism that the military messaging system had right was the system of 
precedence indicators (which Ken is essentially recycling with his labels).  
Urgent traffic gets handled first, meaning that its probablility of getting 
discarded is greatly decreased.  
	The defect in the military messaging system was that there was no airtight 
means of controlling precedence creep.  Anybody with releasing authority 
could assign precedence to a message and the tragedy of commons would set in 
-- I'll mark _my_ traffic with indicators that ensure that it will get 
through.  There were several rules promulgated to attempt to stem this creep, 
but most didn't work very well ... largely because they ignored the 
granularity issues.  For example, one of the rules was that logistics data 
could only be marked priority; it had to be intel or operational messages to 
command immediate and flash precedence.  Well, there are some logistics 
messages that are Really Important ...  This shows up in current diff-serv 
and RSVP deployments where we attempt to discriminate by port number -- 
affording priority queuing service to voice/video.  1) some voice messages 
are a lot more important than others, 2) fairly easy to spoof port numbers.

Any QoS control mechanism needs three parts:
	- a means for end systems to indicate their urgency needs.  To use a 
diff-serv example, this means setting the DS byte in datagrams accordingly.
	- a means for the plumbing infrastructure to treat the urgent traffic with 
expeditious service.  In diff-serv example this is accomplished by giving the 
urgent traffic head-of-line privs in the router queues.  You could do this by 
throttling ingress, but the complexity of that problem strikes me as boggling.
	- an authentication means so that the labeled service is not abused by 
people and for purposes that aren't 'urgent'.  

An help?

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

---

From: Ken Carlberg <[email-masked]>
Date: Sun, 22 Sep 2002 14:30:57 +0100

> [MAP] I see your point. I just think we need to word it so it doesn't
> come across as saying "We' don't care about any laws anywhere and will
> intentionally ignore them" (because that's the impression I've gotten
> from some participants in other discussions). How about "... the eforts 
> should consider the possible impact of regulations in various countries
> with which carriers will have to comply"? 

I can add verbage to the begining to make sure that an arrogant tone is 
not put forth in the statement -- which certainly was not the intention
of the statement.  I can also probably add a point in the 'issues' section 
and note that solutions may want to consider the impact of regulations, 
and thus be flexible where it is deemed apropriate.  

I will agree that the statement is not found in nearly all other drafts, 
but our IEPREP group is comprised of a higher mix of non-traditional IP 
folks.  and more importantly, the work the group produces will mostly
likely be read by a higher percentage of non-technical folks than drafts
produced by other groups.  and this is not a knock on them, but we do 
need to remind folks about some things.

lets take this offline if you wish to discuss this more.  

> [MAP] I don't see this draft as addressing "all IP telephony". 
> Since it addresses the specific application of IEPREP, I believe
> accounting is a requirement. Accounting does not only mean "billing".
> In this case, it means keeping records of the use of the service for
> traffic studies and fraud detection. The service depends on the ability
> to do these two functions. 

the objective is for the draft to be a foundation for IP telephony.
its impossible to write a single draft for "all IP telephony".  thats
why we have been advocating a starting point, and additional drafts
if you need to go beyond it -- ie, like a building block approach.

as for accounting, please recall we don't make a statement about it in
requirements section of the original general document.  we present it as 
an issue, which as the opening paragraph of section 4 says is not to be
confused with a requirement.  if it is critical for what you refer to as 
"assured service" with respect to MLPP, then that would seem to strengthen 
the need for a separate MLPP draft that goes beyond the IP telephony and 
General requirements.  

-ken