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

[<[e-mail]>]

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



Hi Phil,

[e-mail] schrieb:
> 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?

> 
> 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
>  
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 or 1, to indicate whether it's in block or admit.
>  
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 existing protocol]
>  
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: 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
>
>
>
>  

--
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