Subject: [PCN] Comment on draft-taylor-pcn-cl-behaviour-00

From: <[email-masked]>
Date: Sun, 22 Mar 2009 15:34:50 -0000

Tom
 
thanks for working on the draft, sorry i didnt send any comments earlier.
 
couple of things:
 
1. the estimate of congestion seems to be based only on the pkts threshold-marked. i think it should also include th pkts that are excess-traffic-marked, otherwise when pkts start being excess marked the congestion estimate will actualy drop. at least that's what the old cl draft said.
 
2. i dont understand why the reporting system (of the congestion eistmate) is now done periodically, instead of triggered by a signalling msg. [change from olf cl draft to this one]. i dont understand what you mean by 'measureemnt bias' - which i think is the justification for this change?
if you think about a nw with 100 boundary nodes, this would be 10,000 congestion estimates [CLE] to report. many of these will rarely have new flows (distribtuin of flows is long tailed). yet you need to react rapidly to an increase in the CLE - eg you should limit the number of flows that you can admit within this reaction time. you suggest a time perido of 1-3 seconds for this reaction time,. my guess is that this is 2 orders of magnitude out. when i avguely thought about this approach ages ago, i thought the overhead was probably too high to make it interesting in general.
anyway, with on path signalling there is no problem with the signalling 'picking up' the CLE, so a decision can easily be made whether to admit the flow. things are slightly different in the case with the centralised decision node [you have to create a msg to ask for the estimate - but this seems to me very likely less overhead than continually updating CLE for every single inress-egress-aggregate] - and in any case thinking about the centralised case is out odf scope
 
thanks
phil

---

From: Michael Menth <[email-masked]>
Date: Sun, 22 Mar 2009 17:54:56 +0100

Hi Phil, hi Tom,

> 1. the estimate of congestion seems to be based only on the pkts threshold-marked. i think it should also include th pkts that are excess-traffic-marked, otherwise when pkts start being excess mark…
Yes, that's true.

> 2. i dont understand why the reporting system (of the congestion eistmate) is now done periodically, instead of triggered by a signalling msg. [change from olf cl draft to this one]. i dont underst…
If the reception of the NM-rate and ThM-rate at the ingress node 
triggers the measurement of the sent-rate, the 
termination-rate=sent-rate-(NM-rate+ThM-rate) is the difference of two 
timely delayed components. That was meant by measurement bias. Periodic 
measurement at PCN ingress and egress helps to mitigate the problem, but 
periodic reporting is not required.

> if you think about a nw with 100 boundary nodes, this would be 10,000 congestion estimates [CLE] to report. many of these will rarely have new flows (distribtuin of flows is long tailed). yet you need to react rapidly to an increase in the CLE - eg you should limit the number of flows that you can admit within this reaction time.
Phil, that's an optimization that was not yet part of any proposal, but 
it can be applied with any proposal to fight flash crowds.

Regards,

    Michael

>  you suggest a time perido of 1-3 seconds for this reaction time,. my guess is that this is 2 orders of magnitude out. when i avguely thought about this approach ages ago, i thought the overhead was probably too high to make it interesting in general.
> _______________________________________________
> PCN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcn
>   

-- 
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/888-6644, fax: (+49)-931/888-6632
mailto:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn

---

From: Michael Menth <[email-masked]>
Date: Sun, 22 Mar 2009 23:59:20 +0100

Hi Phil and others,

> if you think about a nw with 100 boundary nodes, this would be 10,000 congestion estimates [CLE] to report. many of these will rarely have new flows (distribtuin of flows is long tailed). 
I just discovered that rate values periodically need to be signalled 
from the PCN egress to the PCN ingress because the PCN egress node 
measures them and the PCN ingress node calculates the CLE value and 
calculates the AC decision. Therefore, we have already the reporting 
problem you described in your email. However, the problem is easy to 
solve: calculate AC decision at the PCN egress and signal AC state for 
the IEA (block or admit) to PCN ingress only when it changes.

Regards,

    Michael

---

From: <[email-masked]>
Date: Mon, 23 Mar 2009 03:24:12 -0000

is the CLE calculated at the ingress? the old CL draft has the calculation at the egress. ok, this agrees with yoru last sentence. 
however, your last sentence also has the state [admit/block] transmitted to the ingress. this is ok if [1] the state changes less often than a new flow arrives at eh ingress (for this ingress-egress-aggregate) (if the state chnages more often, then there's less signalling if you piggyback on the signalling msg). [2] if the state [admit/block] is transmitted reliably. note that [1] doesnt apply if teh CLE is piggbybacked on eg an rsvp msg, when the cost of sending teh msg is very low. 
 
personally the case of adding the CLE as an object on eg rsvp msg makes the most sense to me as the basic case. your admit/block case could makes sense in some scenarios.

________________________________

From: Michael Menth [mailto:[email-masked]]
Sent: Sun 22/03/2009 22:59
To: Eardley,PL,Philip,CXR9 R
Cc: [email-masked]
Subject: Re: [PCN] Comment on draft-taylor-pcn-cl-behaviour-00

Hi Phil and others,

Regards,

    Michael

---

From: Michael Menth <[email-masked]>
Date: Mon, 23 Mar 2009 11:07:11 +0100

Hi Phil and all,

[email-masked] schrieb:
> is the CLE calculated at the ingress? 
Yes. See intro in Section 3.2 of
http://tools.ietf.org/html/draft-taylor-pcn-cl-edge-behaviour-00#section-3.2.3
and Section 3.2.2 of
http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/papers/draft-charny-pcn-single-marking-edge-behaviour-00.txt

> the old CL draft has the calculation at the egress. ok, this agrees with yoru last sentence. 
>   
[you refer to the third proposed change in my other email "Comments 
about CL and SM edge behavior"]

> however, your last sentence also has the state [admit/block] transmitted to the ingress. this is ok if [1] the state changes less often than a new flow arrives at eh ingress (for this ingress-egres…
I needed some time to find out what you mean. The idea of piggy-backing 
the CLE information in RSVP RESV messages was proposed by the third 
bullit in Section 4.3 of
http://tools.ietf.org/id/draft-briscoe-tsvwg-cl-architecture-04.txt
As already stated in the draft, this does not work for empty IEAs. 
Moreover, RESV messages are sent every 30 seconds while new measurement 
information is available every ~300 seconds. Therefore, the idea of 
piggybacking seems nice, but it is effective only in case of 
sufficiently many flows or we just don't signal available information.

>  
> personally the case of adding the CLE as an object on eg rsvp msg makes the most sense to me as the basic case. 
As I explained above: it's only applicable when the rate of RSVP RESV 
messages is high enough. You need 100 flows to have such a message every 
300 ms to keep up with the measurment frequency.

> your admit/block case could makes sense in some scenarios.
>   
Also admit/block information per IEA can be piggybacked on RSVP RESV 
message. Then you would signal block/admit whenever a RSVP RESV messages 
comes by and not only state changes as the transmission of RSVP messages 
is not reliable.

Hense, we have two orthogonal questions:

1) Should we signal CLE values or admit/block states? The second can be 
used for other AC methods than CLE, too. For instance for probe-based AC 
for IEAs, this is not per-flow probing, see Section VI.B.3 of
http://www3.informatik.uni-wuerzburg.de/~menth/Publications/papers/Menth08-PCN-Overview.pdf

I believe that signalling only block/admit information is better than 
signalling the CLE or other information which is specific to the applied 
AC algorithm. There are many of them, see Section VI.B of
http://www3.informatik.uni-wuerzburg.de/~menth/Publications/papers/Menth08-PCN-Overview.pdf
And at least PBAC-IEA is helpful for IEAs that are likely to run out of 
traffic. It would be nice if the signalling of AC decisions for IEAs 
could be independent of the deployment scenario.

2) Should PCN use its own signalling or reuse RSVP RESV messages for 
signalling of CLE or admit/block states?

I believe it should have its own signalling method because whether RSVP 
RESV messages can be reused for piggybacking depends on the number of 
flows per IEA and on their signalling protocol which may not necessarily 
be RSVP.

Regards,

    Michael

---

From: <[email-masked]>
Date: Mon, 23 Mar 2009 18:44:29 -0000

300 secs - eh?
you only have to make an admissin decision when you have a new admission request. in my example the rsvp msg. so only then do you need to signal the CLE. why would you signal it continuisly?
 
this leaves the case where the IEA is empty. for simplicity i'd treat this as a corner case, with the following possibilites:
- just admit the new flow. the IEA is empty, chances are this is ok
- same as before, but dont admit if any of the other IEA at this ingerss are doing termination 
- create dummy data 
 
qu 1. signalling CLE vs admit/block. this is a good question. personally i see no great difference. the former seems more general; eg in your PBAC-for-IEA example, you'd just signal CLE either = 0 or 1, to indicate whether it's in block or admit.
qu 2. separate signalling vs piggybacking rsvp. again, fiar question. piggybacking seems easier to me than devising a new protocol [that way, we build on the security, reliability etc of the existing protocol]

From: Michael Menth [mailto:[email-masked]]
Sent: Mon 23/03/2009 10:07
To: Eardley,PL,Philip,CXR9 R
Cc: [email-masked]
Subject: Re: [PCN] Comment on draft-taylor-pcn-cl-behaviour-00

Hi Phil and all,

Regards,

    Michael

---

From: Michael Menth <[email-masked]>
Date: Tue, 24 Mar 2009 00:48:36 +0100

Hi Phil,

> 300 secs - eh?
I thought new CLE values are available every 300 ms and need to be 
provided to the PCN ingress which takes the admission decisions. I 
thought you piggyback this information on the refreshes? Ok, later in 
the text this becomes clear now.

> you only have to make an admissin decision when you have a new admission request. in my example the rsvp msg. so only then do you need to signal the CLE. why would you signal it continuisly?
Ah, ok! I see. You keep the admit/block state at the egress and 
piggyback it on the first RSVP message of a reservation. That's possible 
and avoids any overhead. Clever! It requires the assumption that RSVP is 
used. Is that realistic enough to build PCN signalling on it? I thought 
other people might use other signalling?

> - same as before, but dont admit if any of the other IEA at this ingerss are doing termination 
I call that probing for IEAs (PBAC-IEA), see VI.B.3 of
http://www3.informatik.uni-wuerzburg.de/~menth/Publications/papers/Menth08-PCN-Overview.pdf

> qu 1. signalling CLE vs admit/block. this is a good question. personally i see no great difference. the former seems more general; eg in your PBAC-for-IEA example, you'd just signal CLE either = 0…
More general is the admit/block version as it is already the result of 
the AC calculation and the same for all possible AC methods, e.g. also 
for observation-based AC. The egress needs to calculate the decision 
anyway to do the RSVP piggybacking. Reusing CLE=0 or 1 for PBAC-for-IEA 
is not conform with the heart of CLE semantics which assumes a large 
number of marked or unmarked data traffic as its base. Therefore, I 
consider it rather a hack.

> qu 2. separate signalling vs piggybacking rsvp. again, fiar question. piggybacking seems easier to me than devising a new protocol [that way, we build on the security, reliability etc of the existi…
That is fine with me if you find consensus that the assumption for using 
RSVP for signalling is ok. I am not so sure about that since I believe 
to remember that Joe tried to avoid it. I would like that just the AC 
state (admit/block) is conveyed in that RSVP message as this is the 
maximum abstraction possible.

Regards,

    Michael

---

From: <[email-masked]>
Date: Tue, 24 Mar 2009 00:05:14 -0000

pcn doesnt assume rsvp. we're supposed to work on a doc about requirements /impact on signalling [be it rsvp, nsis, whatever]
 
phil

From: Michael Menth [mailto:[email-masked]]
Sent: Mon 23/03/2009 23:48
To: Eardley,PL,Philip,CXR9 R
Cc: [email-masked]
Subject: Re: [PCN] Comment on draft-taylor-pcn-cl-behaviour-00

Hi Phil,

Regards,

    Michael

---

From: Michael Menth <[email-masked]>
Date: Tue, 24 Mar 2009 01:10:08 +0100

> pcn doesnt assume rsvp. we're supposed to work on a doc about requirements /impact on signalling [be it rsvp, nsis, whatever]
So what does that mean for the signalling of the AC states from the 
egress to the ingress? We need that in the edge behavior drafts. 
Piggybacking that info on RSVP RESV as you described in your previous 
email or extra messages that are unaware of RSVP? The latter one, right?

Regards,

    Michael

---

From: <[email-masked]>
Date: Tue, 24 Mar 2009 01:34:36 -0000

i guess it means: what are the requirements on an extension to a signalling protocol [be it rsvp, nsis, etc] in order to carry the required pcn info

From: Michael Menth [mailto:[email-masked]]
Sent: Tue 24/03/2009 00:10
To: Eardley,PL,Philip,CXR9 R
Cc: [email-masked]
Subject: Re: [PCN] Comment on draft-taylor-pcn-cl-behaviour-00

Regards,

    Michael

---

From: Michael Menth <[email-masked]>
Date: Tue, 24 Mar 2009 09:01:00 +0100

Hi Phil,

I still do not understand. Is the plan to make PCN work by modifying and 
reusing other two-pass signalling protocols such as RSVP to keep the AC 
signalling overhead low or is the plan to have an own PCN signalling 
protocol for that purpose? Both are possible options. For me this calls 
for a consensus question. If RSVP is the de facto standard for things we 
have in mind, it would be ok for me to reuse the RSVP signalling. What's 
the operators perspective? Isn't that a political decision?

Regards,

    Michael

---

From: <[email-masked]>
Date: Tue, 24 Mar 2009 10:00:37 -0000

Hi Phil, Michael,
 
I guess what you need is something that describes an idealised PCN signalling system in abstract terms and then perhaps an example of how RSVP (and perhaps NSIS) can be modified to provide this functionality. >From this is should be possible to create a simple set of requirements in RFC2119 language Plus some optional extras that should be considered. AS I understand it our goal as a WG is to tell a signalling WG what it is we want signalled, where the information needs to go, and which entity needs to have control of the information...
 
I do sometimes get the slight impression that the WG has a strong slant towards RSVP as the signalling of choice, but at this stage I think we need to avoid making that decision.
 
On the issue of policy requiring decisions to be made at ingress rather than egress I quite like Phil's proposal that the egress makes the decision but the ingress can over-ride it. However we need to work out the fallback position from there. I reckon there are three options:
1) Don't terminate any flows - pretty soon the egress will get another termination mark and ask for another flow to be terminated which might not be high priority. Advantage: really simple. Disadvantages: potentially risky if egress always ends up picking high priority flows or if it takes too long for signalling to get back to ingress
2) Ingress chooses another random (but similar-sized) flow from the same IEA to terminate. Advantage: robust in single path case. Disadvantages: breaks down in multipath case, requires ingress to make a decision as to what constitutes a similar size flow.
3) Egress always reports back two flows, ingress chooses which one to terminate. Advantages: simple. Disadvantages: most of the ones above (bad for multipath, potentially risky, both flows may be equally high priority).
 
There is also a potential corner case: If lots of IEAs cross a single bottleneck that is just tipping over into overload then only a few will IEAs will be notified of this. If one of tthe IEAs that is chosen is actually virtually empty it may only have 1 or 2 high priority flows... 
 
Toby

From: [email-masked] on behalf of Michael Menth
Sent: Tue 3/24/2009 08:01
To: Eardley,PL,Philip,CXR9 R
Cc: [email-masked]
Subject: Re: [PCN] Comment on draft-taylor-pcn-cl-behaviour-00

Hi Phil,

Regards,

    Michael

---

From: Michael Menth <[email-masked]>
Date: Tue, 24 Mar 2009 11:57:54 +0100

Hi Toby, hi Phil,

[email-masked] schrieb:
> Hi Phil, Michael,
>  
> I guess what you need is something that describes an idealised PCN signalling system in abstract terms and then perhaps an example of how RSVP (and perhaps NSIS) can be modified to provide this functionality. From this is should be possible to create a simple set of requirements in RFC2119 language Plus some optional extras that should be considered. AS I understand it our goal as a WG is to tell a signalling WG what it is we want signalled, where the information needs to go, and which entity needs to have control of the information...
>   
Ok, then the question boils down to whether AC-relevant information 
should be signalled from the egress to the ingress
a) whenever new marking information is available at the pcn egress node 
(after each measurement interval wich is in the order of 100s msec)
b) when a new flow needs admission. Then the AC info could be 
piggybacked in a two-pass reservation protocol. This requires that some 
two-pass per-flow signalling protocol is used for reservation setup and 
that it is modified to be used for PCN.

a) is ok for IEAs with many flows because then the proportional 
signalling overhead is small.
b) is better for IEAs with only a few flows or even mostly no flow at 
all because then continuous signalling would be large overhead.

I guess that the PCN WG needs to take a decision to make progress, right?

Regards,

    Michael

---

From: Tom Taylor <[email-masked]>
Date: Tue, 24 Mar 2009 08:01:46 -0700

Look at the charter. PCN is not allow to create its own signalling protocol.

Michael Menth wrote:
>> i guess it means: what are the requirements on an extension to a 
>> signalling protocol [be it rsvp, nsis, etc] in order to carry the 
>> required pcn info
>>
>>> pcn doesnt assume rsvp. we're supposed to work on a doc about 
>>> requirements /impact on signalling [be it rsvp, nsis, whatever]
>>>
>>> phil
>>>  
>>>

---

From: <[email-masked]>
Date: Wed, 25 Mar 2009 02:34:13 -0000

>>3) Egress always reports back two flows, ingress chooses which one to terminate. Advantages: simple. Disadvantages: most of the ones above (bad for multipath, potentially risky, both flows may be e…
 
correction, this isnt bad for multipath. the egress knows which flows have been excess traffic marked, so it knows which flows go on an ecmp path that goes thru the bottleneck. this is actually an advantage of making the decision at the egress - otherwise you get into the issues you describe below, or have to expand on approach c) and signal lots of flows which could be potentially terminated.  
 
the whole policy question depends on what sort of policy we're talking about. if it's "global" policy for the whole PCN-domain (eg dont terminate emergency calls) then this policy info is just as visible at the egress as at the ingress. [please confirm /deny whether this correct]
 
if it's per customer policy info then this info is more logically at the ingress than the egress. to me it seems quite reasonable that this type of per customer policy info ifluences admissin control decisions [new call requests from customer X get block if CLE is 5%, new call requests from customer Y get admitted until CLE hits 50%]. however, it also seems reasonable if flow termination doesnt worry about per customer policy info [flows from customer X and Y just as likely to be terminated] . becuase termination is due to some drastic unexpected network event, so lets not worry about which customers we hit. if you agree with this view, then it seems that the egress can decide which flows to terminate just as well as the ingress [assuming it can just as easily avoid termiatning emergency calls]
 
i agree with your comment about rsvp. however, personally i find it easier to talk specific examples, otherwise it's too abstract

From: Moncaster,T,Toby,CXR9 R
Sent: Tue 24/03/2009 10:00
To: [email-masked]; Eardley,PL,Philip,CXR9 R
Cc: [email-masked]
Subject: RE: [PCN] Comment on draft-taylor-pcn-cl-behaviour-00

Hi Phil, Michael,

 

Toby

Hi Phil,

Regards,

    Michael

---

From: Michael Menth <[email-masked]>
Date: Wed, 25 Mar 2009 11:39:20 +0100

> correction, this isnt bad for multipath. the egress knows which flows have been excess traffic marked, so it knows which flows go on an ecmp path that goes thru the bottleneck. this is actually an…
Signalling two flows is just not enough for measured-rate based flow 
termination since many flows need to be terminated. That's why the IDs 
of many marked flows need to be signalled back to the ingress.

>  
> if it's per customer policy info then this info is more logically at the ingress than the egress. to me it seems quite reasonable that this type of per customer policy info ifluences admissin control decisions [new call requests from customer X get block if CLE is 5%, new call requests from customer Y get admitted until CLE hits 50%]. 
Here ee talk about AC policies. This proposal does not work with 
threshold marking since the transition from CLE=0 to CLE=1 is ideally a 
very small load region that is not worth taking advantage of for 
differentiated AC. It might work with excess marking, but there you have 
many other problems.

> however, it also seems reasonable if flow termination doesnt worry about per customer policy info [flows from customer X and Y just as likely to be terminated] . becuase termination is due to some drastic unexpected network event, so lets not worry about which customers we hit. if you agree with this view, then it seems that the egress can decide which flows to terminate just as well as the ingress [assuming it can just as easily avoid termiatning emergency calls]
>   
Not really. One way to handle this situation is to terminate flows with 
high termination priority immediately when termination is required and 
flows with low termination priority only when termination requests 
persist for some time. Hence, overload might be resolved by several 
termination steps when IEAs with high termination priority flows 
terminate more traffic than IEAs with low termination priority flows as 
they start termination later if at all. For exactly this differentiation 
the policy information is needed.

> i agree with your comment about rsvp. however, personally i find it easier to talk specific examples, otherwise it's too abstract
Yes, it's better to have an example in mind. But rsvp is only an example 
for two-pass per-flow reservation protocol and other options are 
possible. However, I don't mind reusing rsvp, either.

---

From: <[email-masked]>
Date: Wed, 25 Mar 2009 12:38:11 -0000

Look closely at it and you will find a milestone for 
"Jul 2009    Submit "Requirements for Signaling of (Pre-) Congestion Information from Egress to Ingress in a DiffServ Domain" to the IESG for consideration as a Informational RFC"
 
Toby

From: [email-masked] on behalf of Tom Taylor
Sent: Tue 3/24/2009 15:01
To: [email-masked]
Cc: [email-masked]
Subject: Re: [PCN] Comment on draft-taylor-pcn-cl-behaviour-00

---

From: <[email-masked]>
Date: Wed, 25 Mar 2009 13:04:21 -0000

Attempt to summarise:
 
If policy info exists throughout the network then the decision can be taken at egress. However it is likely that policy will be only known at ingress (or control node but htats a side issue).
If policy is only at ingress we need to be cautious about flow termination. If we are just getitng into termination (through e.g. everyone suddenly increasing their rates) then we have the luxury of being able to terminate carefully and selectively - thus we can signal to ingress and keep signalling until termination happens. On the other hand if we have a network failure suddenly ramping up traffic across a link then we need to terminate more rapidly. Then the egress is the best palce to do this as it can see which flows are needing termination. Since it is likely we still would want to favour 911/112/999 calls, this seems to suggest we are going to need a requirement for such calls to be identifiable at the egress...
 
So, summary of summary: If the egress can identify the really high priority calls then it seems the best place to make any termination decision. On the other hand the ingress is the better place to make any admission decision...
 
Toby

From: Eardley,PL,Philip,CXR9 R
Sent: Wed 3/25/2009 02:34
To: Moncaster,T,Toby,CXR9 R; [email-masked]
Cc: [email-masked]
Subject: RE: [PCN] Comment on draft-taylor-pcn-cl-behaviour-00

 

Hi Phil, Michael,

 

Toby

Hi Phil,

Regards,

    Michael

---

From: <[email-masked]>
Date: Wed, 25 Mar 2009 17:59:48 -0000

From: Michael Menth [mailto:[email-masked]]
Sent: Wed 25/03/2009 10:39
To: Eardley,PL,Philip,CXR9 R
Cc: Moncaster,T,Toby,CXR9 R; [email-masked]
Subject: Re: [PCN] Comment on draft-taylor-pcn-cl-behaviour-00

[phil] that's a good point. suggests that per customer policy is not really part of the adm ctrl decision?

[phil] that is exactly what i called "global" policy [it isnt "per customer" policy] which i think maybe just as visible at the egress as the ingress.

However, after i sent email i reaslies the point you raised above. if teh egress makes the decision about wat flows to terminate, then it must signal what those flows are to the ingress, since the ingress needs to change tthe policer state so that no more traffic is admitted on the terminated flows. 

this seems to make the general case is better for the ingress to decide which flows to terminate. if there's ecmp, then to make the termination decision you need the egress knowledge about what flows have got excess-marked, which means that the flows go thru the bottleneck. 

/phil

---

From: Michael Menth <[email-masked]>
Date: Wed, 25 Mar 2009 19:49:35 +0100

> [phil] that's a good point. suggests that per customer policy is not really part of the adm ctrl decision?
Yes. No different AC priorities. When the network is full, it's full and 
no more traffic is admitted. But if emergency calls request for 
admission, they are still admitted. Assumption is that they a few and 
small. If not, we can terminate other traffic if necessary.

> However, after i sent email i reaslies the point you raised above. if teh egress makes the decision about wat flows to terminate, then it must signal what those flows are to the ingress, since the…
I don't think that this is important. When a flow is terminated by the 
egress node, this is done, e.g. by sending a RESV TEAR message in RSVP, 
which modifies the policer at the ingress. That's the job of the 
end-to-end signalling protocol.

> this seems to make the general case is better for the ingress to decide which flows to terminate. if there's ecmp, then to make the termination decision you need the egress knowledge about what flo…
Three pieces of information must be combined to select the right flows 
for termination:
1) which flows are marked and therefore eligible for termination, only 
available at egress
2) which flows have high/low termination priority, that's policy, 
probably available at the ingress but not 100% sure
3) what's the rate of the individual flows to compose a set of flows for 
termination with a rate equal to the termination rate. The rates of the 
individual flows can be determined either by signalled traffic 
descriptors or by rate measurement. Don't know where this information is 
usually available if at all.

If 2) and 3) is done at the ingress, then it's much easier to convey the 
information of 1) from the egress to the ingress. So I get the same 
result as you do provided that 2) and 3) is done at the ingress. I just 
use a different reasoning.

Michael

---

From: <[email-masked]>
Date: Mon, 30 Mar 2009 14:32:54 +0200

Hi Phil, hi Michael,

I'm glad to see the work on boundary node beahviour starting. As a general comment to both boundary node behaviour drafts, I'd suggest to put more focus being put on the aspect of measuring ingress-egress aggregates and deployment, respectively. I've followed your discussion and am not very happy to see you discussing "per flow" information being signaled from egress to ingress node.

I think to recall a discussion with Phil, that ingress nodes support per flow signaling (control plane) and per flow conditioning (data plane), whereas egress nodes only support per flow signaling, but no per flow conditioning. The latter implies to me, any egress node measurements are based on aggregates, individual flows can't be identified. I'm too lazy now to dive in the archive, Phil, do you have any recollections?

If it comes to admission control, I really favour PSDM - the required measurement for the egress node is to check whether eg. a new RSVP path message got THmarked and then reply by an RSVP err message (? I think). PSDM also works fine with ECMP (Multipath).

Regards,

Rudiger

/phil