Subject: [Tsvwg] Revised Congestion Notification Process for Real-Time Traffic ID

From: "Jozef Babiarz" <[email-masked]>
Date: Thu, 3 Mar 2005 15:04:07 -0500

I've posted a new version of the Congestion Notification Process for
Real-Time Traffic ID at:
http://www.ietf.org/internet-drafts/draft-babiarz-tsvwg-rtecn-03.txt
<http://www.ietf.org/internet-drafts/draft-babiarz-tsvwg-rtecn-03.txt> 
with the following changes:
 - new ECN semantics that align closer to RFC 3168
 - added description of ECN Marker behavior
 - added an example in Appendix A of a token bucket meter that can be used
to measure real-time traffic
 - added method for detecting mis-marking of ECN bits by routers

Comments are appreciated.

Regards, Joe.
Jozef Babiarz
email: [email-masked]

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

---

From: Baker Fred <[email-masked]>
Date: Thu, 3 Mar 2005 12:32:59 -0800

Thanks, Jozef.

One thing I still don't see in a two-bit marking scheme is how policy 
is externally applied, such as an external decision to drop one flow vs 
another, perhaps based on differing policies applicable to different 
participants. The classic case is the ieprep one, in which the city 
disaster management office needs to place an emergency call to a 
hospital at a time when capacity configured for VoIP access is at full 
tilt, and either preempts (the rule in Canada, or so I'm told) or 
queues for priority access (the rule under GETS in the US).

On Mar 3, 2005, at 12:04 PM, Jozef Babiarz wrote:

>  - added an example in Appendix A of a token bucket meter that can be 
> used to measure real-time traffic
>

---

From: Baker Fred <[email-masked]>
Date: Thu, 3 Mar 2005 13:37:42 -0800

On Mar 3, 2005, at 1:23 PM, Kwok Ho Chan wrote:
> In our model, the external policy applicable to different participants 
> are applied at the application level.  Hence the example you provided 
> of preempting or queuing the session initiation request will be done 
> at the application level and it is the application's responsibility to 
> have the correct policy.

That makes some interesting assumptions about the application. Do your 
SIP proxies have knowledge of the routed path between two SIP 
endpoints, the actual path that data between them will be taking as 
opposed to the multipath route that it might possibly use, the 
instantaneous load on that path, and so on? Are they in fact capable of 
making that decision?

Think in terms of draft-ietf-tsvwg-mlef-concerns-00.txt and the issues 
it raises. Without saying the issues are identical (they're not), they 
are related. Ask yourself the same questions and determine the answers.

To make this work, one has to trust the endpoint to make decisions that 
one-self would make as a network operator in another network. You might 
talk with your network administrator at Nortel and ask him/her whether 
that is a model they normally find acceptable.

---

From: Baker Fred <[email-masked]>
Date: Thu, 3 Mar 2005 14:58:33 -0800

I think this might be easier to describe with a picture...

                     +-----------+
                     | Carol     |
                     +----+------+
                          |
                     +----+------+
                     | Carol ISP |
+----+  +----+      +----+------+
|+----+  +----+          |
||+----+  +----+       ,-+-.        ,---.
|||+----+  +----+     /     \      /     \    +----+  +----+
+|Alice |  Alice|    / Big   \    / Bigger\   |+----+  +----+
  +||    +--+ISP +----  ISP    ----   ISP   ---+|+----+  +----+
   +|    |  |    |    \       /    \       /   |||+----+  +----+
    +----+  +----+     \     /      \     /    +|||Bob |  |    |
                        `---'        `-+-'      +||ISP |  |Bob |
                                       |         +|    |  |    |
                                  +----+------+   +----+  +----+
                                  | Dave ISP  |
                                  +----+------+
                                       |
                                  +----+------+
                                  |  Dave     |
                                  +----+------+

So - there are a lot of "alices" who are talking to a lot of "Bob"s; 
the exact number isn't important other than to say that it is a pretty 
large number - 4, maybe 5 digits at any given time, they use differing 
policy, and there are enough that they are continuously consuming the 
bandwidth configured for voice between the two big ISPs, and already 
over the top. Even numbered instances of Alice attempt to configure ECN 
on their calls; odd numbered Alices don't. For each Bob(j), if 
mod(j,4)==0 or mod(j,4)==1, they accept such a configuration; otherwise 
they don't. So 1/4 of the conversations are getting ECN marked and 
reflected back to the originator. The other 3/4 of the sessions are 
simply experiencing loss. Let's for the sake of argument assume that 
the Alices and Bobs are all configured to drop a session if it 
experiences a 2% loss rate or 1% marking rate, and at this instant 10% 
of all packets are being lost and 5% of all packets are being marked.

In such a case, any given Alice-Bob conversation will experience a 
(total loss)/(# sessions) loss rate or a (total marked)/(# sessions) 
mark rate. Since #sessions is a four or five digit number, each session 
should be experiencing a loss or marking rate on the order of 1/1000 or 
1/10000 - nowhere near the rate to trigger anything.

Now Carol, who is a Truly Special Person, needs to make a Truly Special 
Call to Dave. The requirements being given us by relevant customers in 
this environment want Carol and Dave to experience essentially no loss. 
How does this come to be?

The obvious answer is "four or five digit numbers? At this point is it 
an issue?"

So, recast. We're told that there are quite a number of situations 
where the same picture applies, but the link in question is measured in 
tens-to-hundreds of kilobits, or in other cases single digit megabits, 
and may not be perfectly clean. This could be an DSL connection across 
some form of access network, could be satellite, could be WLAN, ...

The problem here is that the network and the application are not 
necessarily talking with each other unless you pretty specifically make 
a way for them to do so.

So now think about these scenarios, draft-*mlef-concerns*txt in hand, 
and tell me how this works?

---

From: Baker Fred <[email-masked]>
Date: Thu, 3 Mar 2005 15:04:03 -0800

Keeping the complexity out is laudable, and I fully support that.

I think it was Einstein who said that "A scientific theory should be as 
simple as possible, but no simpler." Larry Wall is said to have gone on 
to say that: "Using a simple tool to solve a complex problem does not 
result in a simple solution." I'm concerned that the complexity of the 
problem and the simplicity of the solution don't bring us to a solution 
that practically works.

On Mar 3, 2005, at 2:57 PM, Kwok Ho Chan wrote:

> The notion of trust between the endpoint and the network really 
> depends on who
> uses this technology.  We are not trying to define or solve that with 
> this draft.
> And there may be more than one way that can be done.
>
> The "half-life" of the information (how instantaneous) also depends on 
> the usage.
> The more instantaneous the requirement normally cost more to maintain.
> Many times we ask should we have a very complex and costly solution??
>
> We choose to approach it from the simple end and this draft is just 
> indicating
> the ECN semantics needed to provide the network information for 
> real-time traffic.
>
> Allowing people who choose to use this technology to add the 
> additional values
> depending on their individual problem space.  Keeping the complexity 
> out of ECN
> semantics as much as possible.
>
> -- Kwok --
>
> At 04:37 PM 3/3/2005, Baker Fred wrote:
>
>>> In our model, the external policy applicable to different 
>>> participants are applied at the application level.  Hence the 
>>> example you provided of preempting or queuing the session initiation 
>>> request will be done at the application level and it is the 
>>> application's responsibility to have the correct policy.
>>
>> That makes some interesting assumptions about the application. Do 
>> your SIP proxies have knowledge of the routed path between two SIP 
>> instantaneous load on that path, and so on? Are they in fact capable 
>> of making that decision?
>>
>> Think in terms of draft-ietf-tsvwg-mlef-concerns-00.txt and the 
>> issues it raises. Without saying the issues are identical (they're 
>> not), they are related. Ask yourself the same questions and determine 
>> the answers.
>>
>> To make this work, one has to trust the endpoint to make decisions 
>> that one-self would make as a network operator in another network. 
>> You might talk with your network administrator at Nortel and ask 
>> him/her whether that is a model they normally find acceptable.
>

---

From: Kwok Ho Chan <[email-masked]>
Date: Thu, 03 Mar 2005 17:57:17 -0500

The notion of trust between the endpoint and the network really depends on who
uses this technology.  We are not trying to define or solve that with this 
draft.
And there may be more than one way that can be done.

The "half-life" of the information (how instantaneous) also depends on the 
usage.
The more instantaneous the requirement normally cost more to maintain.
Many times we ask should we have a very complex and costly solution??

We choose to approach it from the simple end and this draft is just indicating
the ECN semantics needed to provide the network information for real-time 
traffic.

Allowing people who choose to use this technology to add the additional values
depending on their individual problem space.  Keeping the complexity out of ECN
semantics as much as possible.

-- Kwok --

At 04:37 PM 3/3/2005, Baker Fred wrote:

>>are applied at the application level.  Hence the example you provided of 
>>preempting or queuing the session initiation request will be done at the 
>>application level and it is the application's responsibility to have the 
>>correct policy.
>
>That makes some interesting assumptions about the application. Do your SIP 
>proxies have knowledge of the routed path between two SIP endpoints, the 
>actual path that data between them will be taking as opposed to the 
>multipath route that it might possibly use, the instantaneous load on that 
>path, and so on? Are they in fact capable of making that decision?
>
>Think in terms of draft-ietf-tsvwg-mlef-concerns-00.txt and the issues it 
>raises. Without saying the issues are identical (they're not), they are 
>related. Ask yourself the same questions and determine the answers.
>

---

From: Kwok Ho Chan <[email-masked]>
Date: Thu, 03 Mar 2005 16:23:24 -0500

Fred:
Thanks for the question.

In our model, the external policy applicable to different participants are 
applied
at the application level.  Hence the example you provided of preempting or 
queuing
the session initiation request will be done at the application level and it 
is the
application's responsibility to have the correct policy.

The Real-Time ECN semantics indicated in this document is for congestion 
notification
by the network, and did not go into the details of how the application uses 
this network
congestion notification with the application admission control policy (a 
brief example
is provided in section 5, but this is only provided as one of many possible 
examples).

Just as an example, the application may decide to only preempt after the 
more severe
congestion condition is reached, and may just not admit new sessions when 
the network
indicates it is at the less severe congestion condition.

But in general, different usage of the network will make different 
decisions based on
the network congestion notification (with 2 examples you pointed out, and 
more is possible).
We leave that to the applications to specify, and not in this document.

Hope this helps.
-- Kwok --

At 03:32 PM 3/3/2005, Baker Fred wrote:
>Thanks, Jozef.
>
>One thing I still don't see in a two-bit marking scheme is how policy is 
>externally applied, such as an external decision to drop one flow vs 
>disaster management office needs to place an emergency call to a hospital 
>at a time when capacity configured for VoIP access is at full tilt, and 
>either preempts (the rule in Canada, or so I'm told) or queues for 
>priority access (the rule under GETS in the US).
>

---

From: Kwok Ho Chan <[email-masked]>
Date: Thu, 03 Mar 2005 18:48:03 -0500

We may want to start simple and only add complexity only when and where it
is needed (noticed I used "only" more than once).

I respect the notion of keeping IP (and the IP network) simple, which many 
people
in the IETF have gotten us this far (and you know, Fred, that I respect you 
on your
many contributions in the IETF).

There are also different ways of approaching a complex problem, we are not
trying to defining the complex problem with this draft (there may be more than
one of such problem).  And definitely not trying to limit ourselves of viewing
a problem from one angle.

At 06:04 PM 3/3/2005, Baker Fred wrote:
>simple as possible, but no simpler." Larry Wall is said to have gone on to 
>say that: "Using a simple tool to solve a complex problem does not result 
>in a simple solution." I'm concerned that the complexity of the problem 
>and the simplicity of the solution don't bring us to a solution that 
>practically works.
>
>>>>of preempting or queuing the session initiation request will be done at 
>>>>the application level and it is the application's responsibility to 
>>>>have the correct policy.
>>>
>>>SIP proxies have knowledge of the routed path between two SIP endpoints, 
>>>the actual path that data between them will be taking as opposed to the 
>>>multipath route that it might possibly use, the instantaneous load on 
>>>that path, and so on? Are they in fact capable of making that decision?
>>>

---

From: Bruce Davie <[email-masked]>
Date: Mon, 07 Mar 2005 18:11:26 -0500

Fred,
 I think there is a simple answer to your question. The draft isn't 
applicable in the scenario you describe, or at least, it isn't applicable 
without some other mechanisms. In this respect it just like conventional 
Diffserv, or simple MLEF - it doesn't, on its own, solve the very real 
problem that you describe. That doesn't necessarily prove it's a bad idea 
(which is another discussion.)

Bruce

--On Thursday, March 3, 2005 2:58 PM -0800 Baker Fred <[email-masked]> 
wrote:

>| +----+  +----+          |
>|| +----+  +----+       ,-+-.        ,---.
>||| +----+  +----+     /     \      /     \    +----+  +----+
> So - there are a lot of "alices" who are talking to a lot of "Bob"s; the
> exact number isn't important other than to say that it is a pretty large
> number - 4, maybe 5 digits at any given time, they use differing policy,
> and there are enough that they are continuously consuming the bandwidth
> configured for voice between the two big ISPs, and already over the top.
> Even numbered instances of Alice attempt to configure ECN on their calls;
> odd numbered Alices don't. For each Bob(j), if mod(j,4)==0 or
> mod(j,4)==1, they accept such a configuration; otherwise they don't. So
> 1/4 of the conversations are getting ECN marked and reflected back to the
> originator. The other 3/4 of the sessions are simply experiencing loss.
> Let's for the sake of argument assume that the Alices and Bobs are all
> configured to drop a session if it experiences a 2% loss rate or 1%
> marking rate, and at this instant 10% of all packets are being lost and
> 5% of all packets are being marked.
>
> In such a case, any given Alice-Bob conversation will experience a (total
> loss)/(# sessions) loss rate or a (total marked)/(# sessions) mark rate.
> Since #sessions is a four or five digit number, each session should be
> experiencing a loss or marking rate on the order of 1/1000 or 1/10000 -
> nowhere near the rate to trigger anything.
>
> The obvious answer is "four or five digit numbers? At this point is it an
> issue?"
>
> So, recast. We're told that there are quite a number of situations where
> the same picture applies, but the link in question is measured in
> necessarily talking with each other unless you pretty specifically make a
> way for them to do so.
>
> So now think about these scenarios, draft-*mlef-concerns*txt in hand, and
> tell me how this works?
>