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

From: [email-masked]
Date: Mon, 2 Dec 2002 10:30:11 EST

In a message dated 11/30/2002 9:24:30 AM Eastern Standard Time, [email-masked] 
writes:

>    > Another question: Was it stated during the presentation that the
>     > packet loss ratio was 40%?
> 
> Four people measured loss between 27% and 30% during that call.  Henning
> measured 0%, and then subsequently amended that to, I believe, 7%.  30%
> loss is typical on the connection to the phone in Nairobi, sometimes
> lower, sometimes higher.
> 
>     > Whatever the loss ratio, why are packets lost? Is it because of
>     > congestion at some point (and discard because the buffer is full)?
> 
> The simple answer is that they're discarded because they weren't paid for.
> There are several thousand 128K DSL circuits terminating on a 384K
> satellite link there, which means, in ISP-speak, about a thousand-to-one
> subscriber ratio, which is one order of magnitude higher than you'd
> typically find here in the States, for instance.  If they could afford to
> pay ten times more for their service, which they can't, because it's not a
> wealthy country, they'd receive service comparable to that which we
> recieve here.  To put things in perspective, if you were in Korea, your
> service would be as much better than US service as US service is than
> Kenyan service.  So there's certainly a lot that can be done if the
> government wanted to improve the quality of service, rather than mandate
> QoS.
> 

[MAP] So take this simple case and apply an emergency. (I'd like to see the 
performance last week right after the bombing in Kenya!)

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? It is my understanding that, at some point, the overload would have 
caused either:

1. all calls to be of unacceptable quality
2. new call attempts would have been rejected

In either case, how would one individual who is supposed to have authorized 
emergency access, get their call through? I and others have asked this 
question numerous times, but have not seen any hint of an answer, just claims 
that one should "overprovision" to prevent this from happening. Clearly, 
overprovisioning or adding capacity in real time can not solve the problem in 
this situation. I'm looking for a concrete solution. I have been lead to 
believe that there is none at present, thus the existance of IEPREP.

Mike Pierce
Artel

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 2 Dec 2002 11:16:43 -0500

On Monday, Dec 2, 2002, at 10:30 America/Montreal, [email-masked] 
wrote:
> [MAP] So take this simple case and apply an emergency. (I'd like to 
> see the performance last week right after the bombing in Kenya!)
>
> 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? It is my understanding that, at some point, the 
> overload would have caused either:
>

	The IP-layer doesn't have the concept of a "call", so (B) can't happen 
at
the IP-layer.  Bill's SIP server is not on the access link (as I 
understand it),
so would not be subject to the emergency -- it would be able to process 
calls
normally without any MLPP.  (Bill please clarify these points.)

	If congestion on the last mile link occurred (which we don't know 
right now),
then it could ONLY be solved using link-specific deployed mechanisms 
(e.g. router
CoS like Sprint/Genuity described would be sufficient).  If congestion 
occurred,
then what would have happened is probably packet loss (after the packet 
buffers
on the access routers filled up).  How much packet loss occurred 
depends on the
depth of those buffers, the offered load, the link capacity, etc.  So 
we don't
know whether congestion occurred (yet, Bill should ask) or exactly what 
happened
if it occurred.

	It is entirely possible that the Nairobi VoIP user was in fact having 
no
problems using his link during that situation.  As of this second, we 
don't
know (and Bill should ask).

> I and others have asked this question numerous times, but have not 
> seen any hint of an answer, just claims that one should 
> "overprovision" to prevent this from happening. Clearly, 
> overprovisioning or adding capacity in real time can not solve the 
> problem in this situation. I'm looking for a concrete solution. I have 
> been lead to believe that there is none at present, thus the existance 
> of IEPREP.

Concrete existing solutions:
	1)	Deploy link-specific QoS.  For DSL see T1/ANSI/ITU-T standards,
		for Ethernet see 802.1p, for cable modems see DOCSIS standards.
	2) 	Deploy access router CoS (a la Sprint/Genuity product offerings).
	     This is already widely available and is outside of IETF's scope 
since
	     it is an implementation detail inside of a router.

Please STOP claiming that concrete solutions to the access link 
congestion
issue have not been offered.  It is a bold-faced lie and it is quite 
tiresome
at this point.

And please STOP claiming that IETF lacks mechanisms that DoD could use 
to
deploy MLPP internally.  DiffServ is on the standards track already with
AF and EF.  So that is another bold-faced lie.

It is just not productive when you keep repeating claims that are 
obviously untrue
to anyone reading the list's archives.

Ran
[email-masked]

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

---

From: "Alan Duric" <[email-masked]>
Date: Mon, 2 Dec 2002 18:21:24 +0100

> 	     it is an implementation detail inside of a router.
 
This is very good start, but not utterly sufficient. Since, mentioned
mechanisms would still not guarantee that packet loss will not happen,
and there's more that can be done in order to have IEPREP call at
certain speech quality level where the purpose of the call can be
conveyed between involved parties, unless the purpose of IEPREP work
related to IEPREP call is to "count" the delivered and lost packets.
There's number of things related to choice of codecs, transcoding,
packet loss concealment mechanisms, jitter buffers (all of the packets
delivered are not necessarily usable if not on time, .) that will effect
conversation in a great manner for the same values of packet loss, so as
said in Yokohama during IEPREP session from packet counting and network
perspective "launch" and "lunch" might sound pretty much the same, but I
guess we all agree in reality of IEPREP initiated call, (figuratively
speaking) those words should not be confused.
So, my question is - does this make sense for IEPREP related work?
			if does how can we contribute to this part?

Regards,
Alan Duric

________________________________________________________________________
____________
Cuius rei demonstrationem mirabilem sane detexi hanc marginis exiguitas
non caperet.

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 2 Dec 2002 13:17:20 -0500

> mechanisms would still not guarantee that packet loss will not happen,

*Nothing* can guarantee that packet loss will not happen.  A trivial 
example
is that if the offered load of legitimate "preferred" traffic exceeds 
the link
capacity, then some packets will be dropped.  Another trivial example 
is that
if there is no path from A to B, then packets from A to B will be lost.
Less trivial examples consider that an adversary might be flooding the 
link
with forged traffic claiming to be "preferred" or other kinds of attacks
or that equipment might fail (e.g. get hit by lightning or a falling 
tree).

Hence, the IEprep question cannot be about "guarantee of zero packet 
loss",
but instead must be (by limtations from physics) of "probability of 
traffic
getting through".

Some of us think that good system engineering, for example including
access link QoS, path-diverse capacity, and over-provisioned backbones
(and for the VoIP case, thoughtful selection of robust codecs), has the
best probability of getting sufficient traffic through.

Ran

---

From: Scott Bradner <[email-masked]>
Date: Mon, 2 Dec 2002 13:40:05 -0500 (EST)

> 2. new call attempts would have been rejected

no- the congested link would not cause the SIP proxies to reject calls
since they have no knowledge of the congestion

Scott

---

From: "Alan Duric" <[email-masked]>
Date: Mon, 2 Dec 2002 19:38:02 +0100

Ran,

> example ...

Great! Then, I think we are fully in agreement in respect to this point.

> Some of us think that good system engineering, for example 
> including access link QoS, path-diverse capacity, and 
> over-provisioned backbones (and for the VoIP case, thoughtful 
> selection of robust codecs), has the best probability of 
> getting sufficient traffic through.

Glad to see that You recognize among other mechanisms the value of
robust codecs (so that's one more point where we are in agreement) for
IEPREP. Nevertheless, my question to the group is (cc-ed from my
previous posting, with certain overhead info, to stress IMHO a few
additional significant factors):

"There's number of things related to choice of codecs, transcoding,
packet loss concealment mechanisms, jitter buffers (all of the packets
delivered are not necessarily usable if not on time, .) that will effect
conversation in a great manner for the same values of packet loss, so as
said in Yokohama during IEPREP session from packet counting and network
perspective "launch" and "lunch" might sound pretty much the same, but I
guess we all agree in reality of IEPREP initiated call, (figuratively
speaking) those words should not be confused. So, my question is - does
this make sense for IEPREP related work?" 

Best regards,
Alan Duric

---

From: Bill Woodcock <[email-masked]>
Date: Mon, 2 Dec 2002 15:11:31 -0800 (PST)

On Mon, 2 Dec 2002, RJ Atkinson wrote:
    > Bill's SIP server is not on the access link (as I understand it),
    > calls normally without any MLPP.  (Bill please clarify these
    > points.)

Currently there's just one server in the system, which we don't regard as
being a production condition, of course.  That server is on a pair of
OC12s, 1ms-2ms off the PAIX, and that link typically runs about about
1%-1.5% utilization, which is fairly typical for big corporate networks.

When we switch to the hardened production servers, of which there are
currently eighteen, we'll have considerably more capacity...  Each of
those is actually within an exchange, and has order of 2gb/sec-5gb/sec of
capacity, typically running at about 0.1% utilization.

    > It is entirely possible that the Nairobi VoIP user was in fact
    > having no problems using his link during that situation.  As of this
    > second, we don't know (and Bill should ask).

He shares that bandwidth with so many other people that the "fairness"
doesn't really impact one flow versus another out of his particular
tail-circuit.  So no, he doesn't notice any impact on his other
performance when he's using his phone.  Or was that not the question?

                                -Bill