Subject: Re: [Ieprep] Internet faults, VoIP demo, etc and others

From: [email-masked]
Date: Fri, 6 Dec 2002 13:22:10 EST

In a message dated 12/5/2002 8:32:51 AM Eastern Standard Time, [email-masked] 
writes:

>    > > [MAP] If 10 or 20 or whatever number of those "several thousands" of 
> end
>     > > users tried to make a VoIP call via that single 384K link, what 
> would
>     > > have happened?
>     > > 1. all calls to be of unacceptable quality
> 
> [BW] Correct, that's a reasonable assumption.
> 
>     > [MAP] I'll repeat the question which I don't believe I've gotten any
>     > concrete answer to: In the case above of the 10 callers from Nairobi, 
> if
>     > one of them was authorized to make emergency calls and the other 9
>     > weren't...
> 
> [BW] Authorized by whom?
> 
>     > [MAP] what specific standardized mechanism (not products) could be
>     > used to provide the required service across the congested 384 kbit/s
>     > satellite link? (The required service is that their call gets set up 
> and
>     > they can talk.)
> 
> [BW] If they were authorized by _me_, that is, if they were paying _me_ to
> deliver their call in preference to the other nine callers, I'd
> policy-route their SIP traffic into a separate PVC at the CPE router.
> That's what I did back in the distant past, when congestion still occurred
> occasionally, and it seemed to work quite satisfactorily at the time.
> 

[MAP] I'll try one more time. The question presumes the following situation:

1. There is a government agency that "authorizes" indiviuduals to get 
priority treatment. (How or why is not the issue here)
2. There is a service provider who has agreed by contract to support this 
capabilitity. The service provider does not "authorize" anyone, but presume 
that they must "authenticate" its use. (Whether they are "paid" to do this is 
not the issue.)
3. There is a single 384 kbit/s path that must carry all the traffic from the 
area (the redundant paths may have been taken out by the terrorist act). 
There is no other "PVC" to route traffic onto. (Why the service provider 
didn't have sufficient backup is not the issue.)
4. There is excessive congestion on the 384 kbit/s path, caused by too many 
voice calls, all of which are getting unacceptable quality. (Any data or 
elastic traffic has already been squeezed out.)

If you don't accept the above as the case being discussed, please do not 
respond.

How is the 1 authorized individual able to get their call through when the 
link is congested by users without the special authorization from the 
government?

Mike Pierce
Artel

---

From: Bill Woodcock <[email-masked]>
Date: Fri, 6 Dec 2002 21:49:26 -0800 (PST)

On Fri, 6 Dec 2002 [email-masked] wrote:
    > priority treatment.

And that would be what, the New World Order government?  Sign me up,
Dogbert!  The example you gave spans two countries plus outer space.  Last
I knew neither outer space nor Kenya were suburbs of Washington D.C.

    > that they must "authenticate" its use. (Whether they are "paid" to do this is

I thought you were worried about traffic getting dropped?  Any traffic
that isn't paid for is going to get dropped.  So you want to make sure
your solution includes some method of at least not guaranteeing that all
of this traffic is going to get dropped.

    > didn't have sufficient backup is not the issue.)

PVC means "Permanent Virtual Circuit."  A PVC is not an alternate or
backup path.  It's a preexisting and widely-used layer-2 tagging
mechanism.

                                -Bill

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

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 12 Dec 2002 13:40:01 -0500

On Friday, Dec 6, 2002, at 13:22 America/Montreal, [email-masked] 
wrote:
> 2. There is a service provider who has agreed by contract to support 
> this capabilitity. The service provider does not "authorize" anyone, 
> but presume that they must "authenticate" its use. (Whether they are 
> "paid" to do this is not the issue.)
> 3. There is a single 384 kbit/s path that must carry all the traffic 
> from the area (the redundant paths may have been taken out by the 
> terrorist act). There is no other "PVC" to route traffic onto. (Why 
> the service provider didn't have sufficient backup is not the issue.)
> 4. There is excessive congestion on the 384 kbit/s path, caused by too 
> many voice calls, all of which are getting unacceptable quality. (Any 
> data or elastic traffic has already been squeezed out.)
>
> If you don't accept the above as the case being discussed, please do 
> not respond.

	The scenario you describe does not sound realistic for IEprep.
In particular, the assumptions do not all seem reasonable to me (and
some few other folks here).

> How is the 1 authorized individual able to get their call through when 
> the link is congested by users without the special authorization from 
> the government?

	Authorisation from NCS (or whoever) is substantially less relevant 
than authorisation
from the organisation that is paying for the access link.  In 
particular, if it
is not NCS's access link on NCS's budget, then NCS does NOT get to set 
the policies
for that link.

	Instead, the end-user organisation who is paying for the access link 
is the
only organisation with authority to set policy for those links.  The 
ISP does NOT
have that authority since it is not their link, so a NCS contract with 
the ISP is
NOT sufficient or terribly relevant.  In this regard, consider that an 
IP access link
is very much like last-mile PSTN to a home.  If there is an emergency, 
that does not
mean that some stranger gets to use one's home telephone unless one 
says they can.
(And I would not suggest that the stranger try to force the issue in 
places like Texas,
where there are decent chances the homeowner is well armed.)

	Note well that ISPs are NOT "common carriers" in the US and in most 
other
countries, unlike PSTN operators.

	For the person who has authorisation from *the end-user organisation 
that is
paying for the access link*, that organisation can configure routers, 
switches,
and other devices to provide such preferential treatment (e.g. 
Class-based queuing
in the routers, switches, or other devices).  This can be configured in 
a variety
of ways, including access-lists, filters, and other 
implementation-specific methods.
A variety of implementation-specific, link-layer, and intra-domain QoS 
methods
(several of which have been described on this list in the past) can be 
used.

	Please note the absence of inter-domain QoS as part of the solution.

Ran
[email-masked]

---

From: Fred Baker <[email-masked]>
Date: Thu, 12 Dec 2002 11:33:29 -0800

At 01:40 PM 12/12/2002 -0500, RJ Atkinson wrote:

>On Friday, Dec 6, 2002, at 13:22 America/Montreal, [email-masked] wrote:
>>capabilitity. The service provider does not "authorize" anyone, but 
>>presume that they must "authenticate" its use. (Whether they are "paid" 
>>to do this is not the issue.)
>>3. There is a single 384 kbit/s path that must carry all the traffic from 
>>the area (the redundant paths may have been taken out by the terrorist 
>>act). There is no other "PVC" to route traffic onto. (Why the service 
>>provider didn't have sufficient backup is not the issue.)

I'm not sure what you're arguing, Ran.

Are you arguing that it is unlikely that a service like GETS might be 
deployed using VoIP technology? If so, you are arguing that the stated 
plans of known government agencies are irrelevant.

Are you arguing that a service provider, perhaps one owned by a government 
agency and perhaps a public one, would choose to not write a contract for 
the capability? Every service provider I know of is killing itself to get 
new revenue.

Are you arguing that there would never be a situation where there is a 
stated bandwidth which is less than infinite when compared to the load that 
might be placed on it at a point in time? If so, a great number of people 
in the Internet will be happy to know that you have decided to fund the 
increase in their available bandwidth.

>         Authorisation from NCS (or whoever) is substantially less 
> relevant than authorisation
>from the organisation that is paying for the access link.  In particular, 
>if it
>is not NCS's access link on NCS's budget, then NCS does NOT get to set the 
>policies
>for that link.

Wonderful, Ran. The point is that the service on the link would have to 
intersect *two* policies: there has to be local service authorization (try 
placing a GETS call from a phone whse owner doesn't pay his bill; I'll bet 
it doesn't work at all), and in addition it needs to have the relevant 
governmental policy authorization.

To be very frank, your response sounds obstructionist. The items Mike put 
forward represent the situation envisioned in the charter of this working 
group. If you don't like the charter, go to the AD. It is chartered; it 
would be nice if you would allow it to be discussed.
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 12 Dec 2002 16:30:55 -0500

> I'm not sure what you're arguing, Ran.

I'm arguing that the assumptions that Mike has made are not all
equally realistic assumptions to make.

>> is not NCS's access link on NCS's budget, then NCS does NOT get to 
>> set the policies
>> for that link.
>
> Wonderful, Ran. The point is that the service on the link would have 
> to intersect *two* policies: there has to be local service 
> authorization (try placing a GETS call from a phone whse owner doesn't 
> pay his bill; I'll bet it doesn't work at all), and in addition it 
> needs to have the relevant governmental policy authorization.

Nope.  If (A) pays for an IP access link, then (A) gets to set the 
policy on their
link.  A's ISP does not get the power to set the policy on that link 
unilaterally
(generally speaking; the details of the ISP's contract with A obviously 
matters here).
The government does not get the power to set the policy on that link 
unilaterally either.

If the government wants to have influence over A's access link(s), it 
seems to several
of us that the government needs to have agreements with both A and A's 
ISP(s).  Absent
specific agreements with A *and* A's ISP(s), then the government simply 
does not have
any right to influence the policy deployed on A's access link.  An 
agreement
between a government and an ISP might impact how that ISP does things 
*inside
the ISP's own network*, but that contract(with the ISP)'s scope could 
not legitimately
include anything belonging to an ISP's customer (e.g. CPE access router 
on the access
link that is owned/operated by the customer).

This is very very basic contract law, at least in places using English 
Common Law
as their basis.  In the US case, there is actually specific 
constitutional
prohibitions from the government just appropriating other folks' 
property.
In other countries, laws probably vary.

Mike's scenario was specific in saying that the government had a 
contract with
the ISP.  It did NOT say there was a contract or other agreement with 
the end-user,
yet Mike's scenario has "government-authorised" folks who might not be
authorised by the end-user (A) consuming bandwidth that is paid for 
solely
by A.

And that *absolutely* does matter.  It is a very important point that 
several
of us have been trying to make for a long while now:

	NCS (or whoever) needs to be thinking about LOTS of contracts,
	encompassing not just the big ISPs, but also the end-users whose
	access links that NCS might want to have NCS's user-base access.

Instead, the repeated misunderstanding from NCS and its contractors is 
that its
sufficient to just have contracts with a few big ISPs.  With the 
Internet's
de-centralised architecture (opposite to PSTN's centralised 
architecture),
the set of agreements needed is pretty significantly larger than with 
the
existing PSTN.

Is that more clear to you ?

Ran

---

From: Fred Baker <[email-masked]>
Date: Thu, 12 Dec 2002 13:54:19 -0800

At 04:30 PM 12/12/2002 -0500, RJ Atkinson wrote:
>Common Law as their basis.  In the US case, there is actually specific 
>constitutional prohibitions from the government just appropriating other 
>folks' property.

Fine. As far as I know, nobody on this list is a lawyer, and this working 
group is not chartered to discuss law. This working group is chartered to 
discuss technology under the assumption that the appropriate legal vehicles 
are in place.

>the repeated misunderstanding from NCS and its contractors is that its 
>Internet's de-centralised architecture (opposite to PSTN's centralised 
>architecture), the set of agreements needed is pretty significantly larger 
>than with the existing PSTN.

OK, so your issue here is that the policy has to apply, by appropriate law 
or contract, to both ends of the link. I'll buy that. Please insert it as 
an unstated assumption in Mike's comments.

Can we get back to dialog on the topic, rather than attempts to derail the 
working group? I can't say I have seen useful dialog on this list since the 
IETF, and I haven't seen comments from you on the particular cases in point 
where Mikes concerns apply and documentation has been sent to the list to 
substantiate them. 
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 13 Dec 2002 08:23:44 -0500

On Thursday, Dec 12, 2002, at 16:54 America/Montreal, Fred Baker wrote:
> I can't say I have seen useful dialog on this list since the IETF, and 
> I haven't seen comments from you on the particular cases in point 
> where Mikes concerns apply and documentation has been sent to the list 
> to substantiate them.

Try reading the responses to Janet Gunn's scenario.
Try also reading the lower portion of the email of mine that you 
misread.

If those got lost in transit to your mailbox, send me a private note and
I'll happily resend them to you privately.

Ran