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

[<[e-mail]>]

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:[e-mail]]
Sent: Mon 23/03/2009 10:07
To: Eardley,PL,Philip,CXR9 R
Cc: [e-mail]
Subject: Re: [PCN] Comment on draft-taylor-pcn-cl-behaviour-00



Hi Phil and all,

[e-mail] 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-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.
>  
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: Michael Menth [mailto:[e-mail]]
> Sent: Sun 22/03/2009 22:59
> To: Eardley,PL,Philip,CXR9 R
> Cc: [e-mail]
> Subject: Re: [PCN] Comment on draft-taylor-pcn-cl-behaviour-00
>
>
>
>
> Hi Phil and others,
>
>  
>> 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).
>>    
> 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
>
> --
> Dr. Michael Menth, Assistant Professor
> University of Wuerzburg, Institute of Computer Science
> Am Hubland, D-97074 Wuerzburg, Germany, room B206
> phone: [phone], fax: [phone]
> mailto:[e-mail]
> http://www3.informatik.uni-wuerzburg.de/research/ngn
>
>
>
>  

--
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: [phone], fax: [phone]
mailto:[e-mail]
http://www3.informatik.uni-wuerzburg.de/research/ngn