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

[Michael Menth <[e-mail]>]

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