Subject: RE: [Sipping] Comments on draft-peterson-sipping-ieprep-00

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 13 Mar 2003 04:09:42 -0500

Some notes below.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Gunn, Janet [mailto:[email-masked]]
> Sent: Tuesday, March 11, 2003 3:22 PM
> To: [email-masked]
> Subject: [Sipping] Comments on draft-peterson-sipping-ieprep-00
> 
> 
[snip]
> 
> Section 2-2 Signaling Encapsulation
> 
> "In the CSN, it is not possible to
>       make an emergency call, for example, from France to the United
>       States.  International ISUP gateways that bridge between different
>       signaling systems will at best discard priority information."
> 
> Actually, it IS possible.  Every month over 3000 GETS  (710...) calls are
> placed from over 50 international locations.  They receive no priority
until
> they get to  US based switch, but most of them DO  receive priority
> treatment within the US.  Granted, it is the "710" that is passing through
> the international gateway, but that IS a "priority label" as well as a
> dialed number, and is not "discarded by the international gateway".
> 

There's no question that if the dialed number contains all of your priority
information, then you can make these prioritized calls internationally
(provided the number is E.164-friendly). The degree to which 710 numbers
receive priority treatment outside the US, however, is a subject of concern,
and that was what my point here was intended to illustrate. I can expand on
the wording above, if it was unclear.

Moreover, the Requirements draft went to great pains, if I recall, to
illustrate that dialed numbers were not sufficient for communicating
priority information (REQ-10). As was pointed out, non-authorized users can
dial these numbers in droves as a sort of DoS attack.

> "It's not clear that it would even be desirable for priority
>       information to be retained when you cross network boundaries - if
>       someone's a government official in Iraq, when they place a call to
>       the United States, should they be afforded the status of a
>       government official here?"
> 
> Just as with the ISUP "Precedence" parameter, the priority information
> could/should indicate (or be mappable to) the context within which it
> applies.
> 

I don't remember that being a requirement, actually, unless it's implicit in
REQ-1 somehow. I can see how that might follow, but it could stand to be
more explicit in the draft. 

The "strong" reading of REQ-4 entails some sort of end-to-end priority for
the Internet that is expected to apply regardless of context. In this case,
one wonder how you do without the strong reading, given that the Internet
lacks the sort of administrative boundries that would ordinary delimit one
telephony context from another.

> Also, the NCS is actively working within the ITU-T to set aside an
> international CPC so calls may be recognized as emergency or priority at
> international gateways.  The issue of determining which countries should
> receive priority is recognized, and messy. 
> 

I can imagine. My comment above was only intended to speak to that
messiness, not as a characterization of ongoing standards work. The fact
that the Internet is, again, largely independent of geopolitical boundries
makes this still more complex in our problem space.

> "Some additional discussion is necessary to understand why signaling
>    encapsulation is insufficient for CSN-IP-CSN architectures.  If this
>    amounts only to the requirement described in Section 7, then
>    signaling encapsulation may still provide some useful properties to
>    the terminating gateway."
> 
> Signaling encapsulation definitely DOES provide "some useful properties".
> But, as you noted above, it does not allow for making "different routing
> decisions for some calls in the presence of a priority indicator".
> 

No disagreement that proxy servers are unable to route based on the content
of SIP MIME bodies. 

> Sec 2.3  ETS in existing SIP networks
> 
> "This points to a fundamental questions: Is ETS opt-in?"
> 
> Personally, I think it is reasonable to expect that ETS will be "opt-in"
for
> the most part, at least in terms of providing any kind of special
services.
> But I think it is also reasonable to hope that "transparent" networks will
> pass the priority information (directly or encapsulated) even if they do
not
> DO anything with it.  Similarly, I want to make it as easy as possible for
a
> network to make the decision to opt-in.
> 

One question I raise in my draft is how much value there is in having
intermittent priority treatment in the path of the call - which is really a
question about where congestion arises and how to effectively combat it.
Unfortunately, I think that congestion could conceivably appear anywhere in
the path of a call. While having some ETS-aware segments of a call path
improves the odds of completing prioritzed calls, it is very difficult to
anticipate how greatly the odds will be improved, and how successful the
overall system will be in practical emergencies.

Clearly, opting in will involve at the least having special implementations
of network elements and having configurations dictated by the agency
responsible for administering ETS. It may be easy to make the decision to
opt in, but it will not be trivial to bear out. I would strongly maintain
that it will be impossible to force everyone to opt in (it's very unlikely
that my private LAN and its SIP devices will develop a relationship with the
relevant gov't agencies).

> "and even then,
>    there is no guarantee that fully compliant implementations will be
>    ubiquitously deployed, nor configured to behave appropriately in an
>    ETS situation."
> 
> This is true, even in the current CSN, and has not precluded the
> implementation of  a useful, near ubiquitous, service.
> 

The PSTN admits of far greater centralization that the Internet and its
services.

Unless there were a regulatory push that essentially made SIP's core
architecture illegal (by legislating the oversight of monolithic service
providers similar to the current LEC community), it is unlikely that ETS
would ever enjoy near-ubiquitous SIP deployment, in my opinion.

> "...only networks that develop relationships with the
>    relevant government agencies, and are given proper configuration
>    information by those agencies, will do so."
> 
> True, but the hope is to make it as painless as possible for networks to
> develop those relationships.
> 
> 3.1 General Requirements
> 
> REQ-4 "The 'mapping of schemes' requirement could be taken to be
>    strong or weak." 
> 
>  I had interpreted it as "weak", in some ways analogous to the ISUP
> Precedence parameter.
> 

Okay. I think that is more plausible than the strong interpretation.

> REQ-7
> (wrt MLPP in the CSN) "It's never unclear within a certain network
>    how a given element will behave when presented with a prioritization
>    indicator."
> 
> Unfortunately, this is not true.  The standards dictate what SHOULD
happen,
> but the actual implementation often does not reflect the standards.
> 

We in the standards business flatter ourselves too much sometimes that our
standards will be implemented. But the best we can do is to mandate common
behavior and hope that the desire for interoperability will lead to its
implementation. The behavior of particular elements in the standard should
be deterministic - we can't mitigate the risk that implementers will opt for
non-compliance. For the standard to disregard deterministic behavior of
elements seems to invite interoperability failures that might not happen
otherwise.

> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 13 Mar 2003 04:28:15 -0500

Well, I hope my draft doesn't miss those points - it was intended to try to
draw them out a bit. I agree that the three 'wants' that you identify below
are all desirable; what the draft questions is whether they are consistent
with the other requirements (in the case of the 2nd want) and whether they
are ultimately achievable.

Especially on the first want, the issue of partial ETS coverage is one that
I think really requires further examination. The system is clearly intended
to increase the chances of call completion, but I think some further
analysis of the effects of partial ETS coverage is required before we can
seriously assess the value added by the ETS concept for SIP. Universal
adoption seems profoundly unlikely to me, so in my mind the important cases
are partial coverage. No doubt it is true that the closer ETS is to the
caller, the better off you are.

Agreed that modeling a SIP prioritization system on GETS is probably
ill-advised.

Jon Peterson
NeuStar, Inc.

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Tuesday, March 11, 2003 4:42 PM
> To: Gunn, Janet
> Cc: [email-masked]
> Subject: Re: [Sipping] Comments on draft-peterson-sipping-ieprep-00
> 
> 
> To amplify what Janet wrote: I think Jon's draft misses the point that 
> we want
> 
> - networks that don't want to play to at least not get in the way (i.e., 
> not prevent delivery of services downstream)
> 
> - require minimal changes to end systems
> 
> - support non-ISUP originators (e.g., SIP soft-terminals)
> 
> It's a nice side benefit if 'joining' ETS is easy, but the primary 
> consideration is that needs it work with standards-compliant SIP 
> elements (in particular, proxies) that are unaware of it.
> 
> It should also have the "earliest possible" property, i.e., as the 
> network becomes ETS-aware, suitable treatment gets applied closer to the 
> caller.
> 
> Thus, success is not measured by whether we get 100% coverage or 
> international coverage, but rather whether I can plug in a SIP terminal 
> or use my laptop and get whatever service I can.
> 
> One could clearly model the SIP solution on the GETS system, by having a 
> "gateway" with a specific SIP address (equivalent to the 710 number), 
> which then prompts for another SIP address or tel URI. From scaling and 
> architectural perspectives, this seems much worse.
> 
> The draft tries to make this clear by emphasizing the different network 
> types.
> 
> Gunn, Janet wrote:
> > My personal (not representing any organization) comments on
> > draft-peterson-sipping-ieprep-00
> > 
> > Some of these comments address details rather than the 
> overall sense, but I
> > think it is important to keep even the details straight.
> > 
> > placed from over 50 international locations.  They receive 
> no priority until
> > Personally, I think it is reasonable to expect that ETS 
> will be "opt-in" for
> > the most part, at least in terms of providing any kind of 
> special services.
> > pass the priority information (directly or encapsulated) 
> even if they do not
> > DO anything with it.  Similarly, I want to make it as easy 
> as possible for a
> > Unfortunately, this is not true.  The standards dictate 
> what SHOULD happen,

---

From: "Gunn, Janet" <[email-masked]>
Date: Thu, 13 Mar 2003 14:51:27 -0500

Not "the only meaningful customer", but certainly "one of the meaningful
customers".

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]]
[snip]

And again, private packet networks are not the native environment for SIP -
nor would I have thought that they were the only meaningful customer of
IEPREP. The MSF architecture specified by the document referenced above
relies on numerous assumptions that are not general Internet tenets. That
much said, these private networks are not harmful to the Internet, they are
potentially useful, and so on. However, I don't think any ETS system that
relied exclusively on the traversal such networks would be a general
solution for Internet emergency preparedness. 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "King, Kimberly S." <[email-masked]>
Date: Thu, 13 Mar 2003 20:58:32 -0500

Jon said:

>If the reality is
>that congestion is more likely to arise in other parts of the system
>(like, the access links), then alleviating congestion at gateways is
unlikely
>to increase the overall odds of call completion significantly. If odds are
>that you will never be able to get to the gateways, then managing gateway
>congestion will make little difference; we need to know if the
>interposition of one administrative domain that does not support ETS in a
call's path
>crushes the odds that calls will complete reliably in emergencies. This
>is the sort of analysis that needs to be done. 

Okay, the ideas I'm about to present represent my personal thoughts. 

Why should ETS need to justify the absence of congestion in the access links
or other parts of the network (thereby proving optional preferential
treatment is justified) when the default system operates without respect to
transport congestion?  We are just trying to increase our odds with the
default system.  Why not have transport congestion issues, where
appropriate, handled independently?

For example, there are Internet Telephony Service Providers (ITSPs) today
that are selling VoIP using SIP where the ITSP has no control over access
links or any administrative domains over which the packets flow.  If
transport layer congestion occurs then perhaps some signaling packets get
dropped or voice quality is reduced.  If gateway congestion occurs then no
ports are available and I'm assuming some SIP VoIP sessions are given a fast
busy or re-routed to an alternate gateway.  I take as an assumption that if
a provider spent the money on gateway resources by investing in many
connections to the PSTN (these are $$$) that they were smart enough to
ensure, given reasonable traffic assumptions, that signaling isn't going to
be dropped very often (at least near the gateway) and that on-going call
quality can be maintained fairly well.  This represents the standard network
offering that I'll assume works well enough even when the gateway is full. 

Suppose we want to do better than the default service offering by allowing a
preferential access to gateway resources during times of gateway congestion.
Examine the scenario of an ETS supporting fully loaded gateway.  In this
case, the total traffic is the same as the maximum traffic load that could
be supported.  If the call quality was sufficient before, it should be
sufficient now too.  All that has changed is the proportion of ETS sessions
is possibly greater.  I'm aware this is different than GETS, but GETS
provides a good model.  It doesn't "fix" the PSTN under all circumstances;
it just uses the default network to increase the probability of success.
Why shouldn't the SIP ETS provided by an ITSP adhere to the same "take the
default offering and increase the probability of success"?  

>I agree that managing gateway congestion by routing prioritized calls to
>reserved emergency gateways is realistic. But if it turns out that this
>is the only aspect of managing prioritization that is actually realistic,
>then that tells us something about the mechanism (for one thing, that all
SIP
>calls whose priority can be managed would have telephone numbers in
>their Request-URI). This could have significant ramifications for the
ongoing
>design work.

I agree with you that if gateways are the only issue then this could affect
the design.  However, are there not media or application servers that might
also provide such preferential access?  

>On totally private networks, I find the whole ETS SIP concept entirely
>plausible. I would note that the "I" in "IEPREP" is for Internet,
>though. I
>have always understood that to be the capital-"I" Internet, as in
>RFC3271.

This is a good point.  I believe many in ieprep have interest in developing
standards for IP networks (both those that are part of the Internet and
those that are not).    

Kimberly

---

From: "Gunn, Janet" <[email-masked]>
Date: Fri, 14 Mar 2003 10:15:49 -0500

I agree.

It makes much more sense (in a private IP network) to rely on standards that
are accepted in the public (Big "I") Internet, than to rely on proprietary
approaches and have future interoperability problems.

-----Original Message-----
From: King, Kimberly S. [mailto:[email-masked]]

Jon said:

snip

Kimberly

---

From: "Gunn, Janet" <[email-masked]>
Date: Mon, 17 Mar 2003 12:15:40 -0500

Alternatively, I would phrase it as setting aside 90% of the capacity for
NON-ETS traffic. 

-----Original Message-----
Major snip

> Agreed that partial deployment of ETS will be no worse than no deployment
> (provided that security issues are all handled well - if the system is
> exploitable, it could be quite a bit worse). I also agree that the
scarcity
> of gateway resources is one of the paramount concerns.

Any such system needs to limit the high-priority set-aside to some safe 
number so that even compromise does not significantly degrade the system 
below the non-enabled state. After all, the volume of ETS calls is 
usually only a tiny fraction of the total system capacity, so if you set 
aside, say, 10% of the capacity for ETS, you can limit the worst-case 
exposure.
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Gunn, Janet" <[email-masked]>
Date: Mon, 17 Mar 2003 12:30:04 -0500

This analogy (snipped bit included "(This is somewhat similar to the need to
dial 1010xxx to reach a 
> 710-aware carrier in the GETS system.)") actually is (in my opinion) very
important.  

The FIRST objective is to be able to pass the priority/ETS information to
the pieces that know what to do with it.  We don't want to LOSE the
priority/ETS information, just because the path goes through non-ETS-aware
devices

The SECOND objective is to DO SOMETHING based on the priority/ETS
information where possible (and that objective is, itself, prioritized in
terms of "where it will do the most good").

-----Original Message-----

Major snip

> A system which has no effect on congestion in the LEC, but is better than
> nothing.

You solve the problems you can solve...