Re: [PCN] Comment on draft-taylor-pcn-cl-behaviour-00
Michael Menth <menth@informatik.uni-wuerzburg.de> Mon, 23 March 2009 23:47 UTC
Return-Path: <menth@informatik.uni-wuerzburg.de>
X-Original-To: pcn@core3.amsl.com
Delivered-To: pcn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8BCD28C1D0 for <pcn@core3.amsl.com>; Mon, 23 Mar 2009 16:47:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_72=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ve3OQTeX1RPe for <pcn@core3.amsl.com>; Mon, 23 Mar 2009 16:47:52 -0700 (PDT)
Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 9E2733A69DC for <pcn@ietf.org>; Mon, 23 Mar 2009 16:47:46 -0700 (PDT)
Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 4E241199077; Tue, 24 Mar 2009 00:48:36 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 416FD199076; Tue, 24 Mar 2009 00:48:36 +0100 (CET)
Received: from [92.226.212.240] (g226212240.adsl.alicedsl.de [92.226.212.240]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id E5F3EA071C; Tue, 24 Mar 2009 00:48:35 +0100 (CET)
Message-ID: <49C81FD4.7070906@informatik.uni-wuerzburg.de>
Date: Tue, 24 Mar 2009 00:48:36 +0100
From: Michael Menth <menth@informatik.uni-wuerzburg.de>
Organization: University of Wuerzburg
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: philip.eardley@bt.com
References: <4A916DBC72536E419A0BD955EDECEDEC044410C9@E03MVB1-UKBR.domain1.systemhost.net> <49C6C2C8.7050209@informatik.uni-wuerzburg.de> <4A916DBC72536E419A0BD955EDECEDEC044410CD@E03MVB1-UKBR.domain1.systemhost.net> <49C75F4F.2050309@informatik.uni-wuerzburg.de> <4A916DBC72536E419A0BD955EDECEDEC044410D7@E03MVB1-UKBR.domain1.systemhost.net>
In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC044410D7@E03MVB1-UKBR.domain1.systemhost.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de
Cc: pcn@ietf.org
Subject: Re: [PCN] Comment on draft-taylor-pcn-cl-behaviour-00
X-BeenThere: pcn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: menth@informatik.uni-wuerzburg.de
List-Id: PCN WG list <pcn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pcn>, <mailto:pcn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcn>
List-Post: <mailto:pcn@ietf.org>
List-Help: <mailto:pcn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcn>, <mailto:pcn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Mar 2009 23:47:53 -0000
Hi Phil, philip.eardley@bt.com 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:menth@informatik.uni-wuerzburg.de] > Sent: Mon 23/03/2009 10:07 > To: Eardley,PL,Philip,CXR9 R > Cc: pcn@ietf.org > Subject: Re: [PCN] Comment on draft-taylor-pcn-cl-behaviour-00 > > > > Hi Phil and all, > > philip.eardley@bt.com 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:menth@informatik.uni-wuerzburg.de] >> Sent: Sun 22/03/2009 22:59 >> To: Eardley,PL,Philip,CXR9 R >> Cc: pcn@ietf.org >> 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: (+49)-931/888-6644, fax: (+49)-931/888-6632 >> mailto:menth@informatik.uni-wuerzburg.de >> 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: (+49)-931/888-6644, fax: (+49)-931/888-6632 > mailto:menth@informatik.uni-wuerzburg.de > 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: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn
- [PCN] Comment on draft-taylor-pcn-cl-behaviour-00 philip.eardley
- Re: [PCN] Comment on draft-taylor-pcn-cl-behaviou… Michael Menth
- Re: [PCN] Comment on draft-taylor-pcn-cl-behaviou… Michael Menth
- Re: [PCN] Comment on draft-taylor-pcn-cl-behaviou… philip.eardley
- Re: [PCN] Comment on draft-taylor-pcn-cl-behaviou… Michael Menth
- Re: [PCN] Comment on draft-taylor-pcn-cl-behaviou… philip.eardley
- Re: [PCN] Comment on draft-taylor-pcn-cl-behaviou… Michael Menth
- Re: [PCN] Comment on draft-taylor-pcn-cl-behaviou… philip.eardley
- Re: [PCN] Comment on draft-taylor-pcn-cl-behaviou… Michael Menth
- Re: [PCN] Comment on draft-taylor-pcn-cl-behaviou… philip.eardley
- Re: [PCN] Comment on draft-taylor-pcn-cl-behaviou… Michael Menth
- Re: [PCN] Comment on draft-taylor-pcn-cl-behaviou… toby.moncaster
- [PCN] Signalling of admission control info from e… Michael Menth
- Re: [PCN] Comment on draft-taylor-pcn-cl-behaviou… Tom Taylor
- Re: [PCN] Comment on draft-taylor-pcn-cl-behaviou… philip.eardley
- Re: [PCN] Comment on draft-taylor-pcn-cl-behaviou… Michael Menth
- Re: [PCN] Comment on draft-taylor-pcn-cl-behaviou… toby.moncaster
- Re: [PCN] Comment on draft-taylor-pcn-cl-behaviou… toby.moncaster
- Re: [PCN] Comment on draft-taylor-pcn-cl-behaviou… philip.eardley
- [PCN] FT at ingress or egress? Michael Menth
- Re: [PCN] Comment on draft-taylor-pcn-cl-behaviou… Ruediger.Geib