From rbriscoe@jungle.bt.co.uk Mon Aug 2 07:42:56 2010
Return-Path:
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 4EC073A68FD for ; Mon, 2 Aug 2010 07:42:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.455
X-Spam-Level:
X-Spam-Status: No, score=-1.455 tagged_above=-999 required=5 tests=[AWL=0.662, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_LOW=-1]
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 ZplHqye7M9gy for ; Mon, 2 Aug 2010 07:42:49 -0700 (PDT)
Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id E04BD3A6B36 for ; Mon, 2 Aug 2010 07:42:48 -0700 (PDT)
Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Aug 2010 15:43:15 +0100
Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Aug 2010 15:43:15 +0100
Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1280760194350; Mon, 2 Aug 2010 15:43:14 +0100
Received: from MUT.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id o72EhCCr001102; Mon, 2 Aug 2010 15:43:12 +0100
Message-Id: <201008021443.o72EhCCr001102@bagheera.jungle.bt.co.uk>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 02 Aug 2010 15:43:17 +0100
To: tsvwg@ietf.org
From: Bob Briscoe
In-Reply-To: <20100802133003.85C023A68D0@core3.amsl.com>
References: <20100802133003.85C023A68D0@core3.amsl.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158
X-OriginalArrivalTime: 02 Aug 2010 14:43:15.0270 (UTC) FILETIME=[0A0F3660:01CB3251]
Cc: PCN IETF list
Subject: Re: [PCN] I-D Action:draft-ietf-tsvwg-ecn-tunnel-09.txt
X-BeenThere: pcn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PCN WG list
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 02 Aug 2010 14:42:56 -0000
tsvwg folks,
To satisfy the review comments ecn-tunnel received while going
through IETF last call and GENART review, I've revised it to draft-09
before it goes to the IESG. No changes to technical content - only editorial.
The changes are listed within the doc which is here:
I have also repeated them below:
From ietf-08 to ietf-09 (current): Added change log entry for -07 to
-08 that was previously omitted.
* Changes to standards action text:
+ Added RFC4774 to 'Updates:' header (the draft always has
extended the advice in RFC4774 (BCP124) which said very
little about tunnels. The GENART reviewer merely pointed
out that the header did not highlight this fact.)
* Editorial changes:
+ Abstract: s/providing backward compatibility./thus ensuring
backward compatibility./
+ Moved PCN-related text motivating changes to decapsulation
from "Default Tunnel Egress Behaviour" (Section 4.2) to
"Motivation for Changing Decapsulation" (Section 5.3.2)
where it was merged with existing similar text.
+ In the non-normative Design Principles avoided using words
in lower case where they were in contexts that might make
them confusable with upper case RFC2119 normative language.
+ Added Stephen Hanna and Ben Campbell to acks and corrected
spelling of Agarwal.
+ Deleted endnote discussing corner case with IKEv2 manual
keying (identified as "to be removed before publication
following SecDir review").
+ Deleted Appendices D & E on why existing ingress & egress
tunnelling behavour impede PCN and the endnotes that
referred to them (identified as "to be removed before
publication").
+ Various minor corrections pointed out by reviewers.
Bob
Bob
At 14:30 02/08/2010, Internet-Drafts@ietf.org wrote:
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>This draft is a work item of the Transport Area Working Group
>Working Group of the IETF.
>
>
> Title : Tunnelling of Explicit Congestion Notification
> Author(s) : B. Briscoe
> Filename : draft-ietf-tsvwg-ecn-tunnel-09.txt
> Pages : 42
> Date : 2010-08-02
>
>This document redefines how the explicit congestion notification
>(ECN) field of the IP header should be constructed on entry to and
>exit from any IP in IP tunnel. On encapsulation it updates RFC3168
>to bring all IP in IP tunnels (v4 or v6) into line with RFC4301 IPsec
>ECN processing. On decapsulation it updates both RFC3168 and RFC4301
>to add new behaviours for previously unused combinations of inner and
>outer header. The new rules ensure the ECN field is correctly
>propagated across a tunnel whether it is used to signal one or two
>severity levels of congestion, whereas before only one severity level
>was supported. Tunnel endpoints can be updated in any order without
>affecting pre-existing uses of the ECN field, thus ensuring backward
>compatibility. Nonetheless, operators wanting to support two
>severity levels (e.g. for pre-congestion notification--PCN) can
>require compliance with this new specification. A thorough analysis
>of the reasoning for these changes and the implications is included.
>In the unlikely event that the new rules do not meet a specific need,
>RFC4774 gives guidance on designing alternate ECN semantics and this
>document extends that to include tunnelling issues.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-ecn-tunnel-09.txt
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>
>
>
________________________________________________________________
Bob Briscoe, BT Innovate & Design
From philip.eardley@bt.com Tue Aug 3 05:22:54 2010
Return-Path:
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 D00B13A67A2 for ; Tue, 3 Aug 2010 05:22:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.34
X-Spam-Level:
X-Spam-Status: No, score=-0.34 tagged_above=-999 required=5 tests=[AWL=-0.894, BAYES_50=0.001, HELO_MISMATCH_COM=0.553]
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 uXXBX36GqbLP for ; Tue, 3 Aug 2010 05:22:53 -0700 (PDT)
Received: from smtpe1.intersmtp.com (smtp63.intersmtp.COM [62.239.224.236]) by core3.amsl.com (Postfix) with ESMTP id AFB9F3A6889 for ; Tue, 3 Aug 2010 05:22:52 -0700 (PDT)
Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.1.436.0; Tue, 3 Aug 2010 13:23:20 +0100
Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.112]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Tue, 3 Aug 2010 13:23:19 +0100
From:
To:
Date: Tue, 3 Aug 2010 13:23:19 +0100
Thread-Topic: [PCN] PCN WGLC for the CL and SM edge behaviour drafts
Thread-Index: AcsvUmp4c3BoYIymTYWmDJjr8aN8ggDpV5xw
Message-ID: <4C22FF8FA5626046BF68899C06A0C9F71120F641E2@EMV67-UKRD.domain1.systemhost.net>
In-Reply-To: <4C51D328.2020102@informatik.uni-wuerzburg.de>
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-GB
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: pcn@ietf.org
Subject: Re: [PCN] PCN WGLC for the CL and SM edge behaviour drafts
X-BeenThere: pcn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PCN WG list
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 03 Aug 2010 12:22:54 -0000
Lcle is horrid. Let's stick with the name we're familiar with.
<>
I find this change hard to understand ['continuous report suppression' =3D =
?]
Repsup is hard to guess; maxnorep was easier.
I can see why you want the names for limits to be easily distinguished from=
the names of the variable. I'd simply use T_x and t_x [ie the data x is re=
ported once the timer t_x has reached the value T_x]
I also suggest better names than 'mi' - it's hard to guess this means measu=
rement interval, there are no prizes for as few characters as possible.
I don't like your change of 'amount of traffic to be terminated' to 'Termin=
ation rate'. The latter suggests to me a continual process where you keep t=
erminating this amount, whereas the former suggest a one-off process.
You deleted the phrase that the decision point MAY choose to terminate in o=
ne step or it MAY choose to spread over a longer period. I think it's bette=
r with this phrase.
In general, I don't like the changes round the end of 3.3.2
<>
'sent' is better than 'admitted'. I think it would be better to say somethi=
ng like:
The PCN-ingress-node MUST provide an estimate of the current rate of PCN-tr=
affic that is destined for this specific PCN-egress-node.
<>
Ruediger, does this change pass your test?
5.4
<>
Better:
The reference rates on each inward link, PCN-threshold-rate and PCN-excess-=
rate; see Section 2.
Thanks
phil
> -----Original Message-----
> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On
> Behalf Of Michael Menth
> Sent: 29 July 2010 20:15
> Cc: pcn@ietf.org
> Subject: Re: [PCN] PCN WGLC for the CL and SM edge behaviour drafts
>
>
> Hi Tom, hi all,
>
> sorry for being late. I made some proposals for better
> formulations in
> some cases when I found a passage hard to understand. I also suggest
> improved names for variables using the following idea:
> Txyz: a timer name
> Dxyz: the duration after which timer Txyz expires
> I suggested more selfexplaining timer names for xyz
> Suggest to change the variable name:
> admission-decision-threshold (CLElimit) -> CLE limit (Lcle),
> otherwise
> this is confusing.
>
> I hope my comments are all well visible in the attached Word
> file since
> Word crashed twice while revising the doc.
>
> I also took care of Ruediger's comment and added appropriate text.
>
> Kind regards,
>
> Michael
>
>
> Scott O. Bradner schrieb:
> > this starts a WGLC for
> > "PCN Boundary Node Behaviour for the Controlled Load (CL) Mode
> > of Operation" (draft-ietf-pcn-cl-edge-behaviour) and
> > "PCN Boundary Node Behaviour for the Single Marking (SM) Mode
> > of Operation" (draft-ietf-pcn-sm-edge-behaviour).
> >
> > comments to the list by July 24 please
> >
> > Scott
> > _______________________________________________
> > PCN mailing list
> > PCN@ietf.org
> > https://www.ietf.org/mailman/listinfo/pcn
> >
>
> --
> PD Dr. habil. Michael Menth, Assistant Professor
> University of Wuerzburg, Institute of Computer Science
> Am Hubland, D-97074 Wuerzburg, Germany, room B206
> phone: (+49)-931/31-86644 (new), fax: (+49)-931/31-86632
> (new) mailto:menth@informatik.uni-wuerzburg.de
> http://www3.informatik.uni-wuerzburg.de/research/ngn
>
>
From menth@informatik.uni-wuerzburg.de Tue Aug 3 10:00:31 2010
Return-Path:
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 C3B983A6918 for ; Tue, 3 Aug 2010 10:00:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.206
X-Spam-Level:
X-Spam-Status: No, score=-1.206 tagged_above=-999 required=5 tests=[AWL=0.443, BAYES_50=0.001, GB_I_LETTER=-2, HELO_EQ_DE=0.35]
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 jSLWAzgmQpOa for ; Tue, 3 Aug 2010 10:00:30 -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 0454A3A67D3 for ; Tue, 3 Aug 2010 10:00:26 -0700 (PDT)
Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id E2482218F5; Tue, 3 Aug 2010 19:00:53 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id DEEA549042; Tue, 3 Aug 2010 19:00:53 +0200 (CEST)
X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de
Received: from [132.187.12.151] (win3151.informatik.uni-wuerzburg.de [132.187.12.151]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTPSA id BAEDB5CDAE; Tue, 3 Aug 2010 19:00:53 +0200 (CEST)
Message-ID: <4C584B41.2070006@informatik.uni-wuerzburg.de>
Date: Tue, 03 Aug 2010 19:00:49 +0200
From: Michael Menth
Organization: University of Wuerzburg
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: philip.eardley@bt.com
References: <4C22FF8FA5626046BF68899C06A0C9F71120F641E2@EMV67-UKRD.domain1.systemhost.net>
In-Reply-To: <4C22FF8FA5626046BF68899C06A0C9F71120F641E2@EMV67-UKRD.domain1.systemhost.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: pcn@ietf.org
Subject: Re: [PCN] PCN WGLC for the CL and SM edge behaviour drafts
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
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 03 Aug 2010 17:00:31 -0000
Hi Phil,
philip.eardley@bt.com schrieb:
> Lcle is horrid. Let's stick with the name we're familiar with.
>
Well, consistently taking D for durations, T for timers, and L for
limits suggests to move CLElimit to Lcle. I'm sure that this is only a
matter of familiarization. However, as such a limit is used only once, I
do not insist on the one letter indication rule for limits.
> <>
> I find this change hard to understand ['continuous report suppression' = ?]
> Repsup is hard to guess; maxnorep was easier.
>
I do not insist on _repsup for report suppression, _maxnorep works also
for me. However, the duration is not really the duration after which a
report must be sent because the next report will be sent only after the
next measurement interval is over. Therefore, the maximum time during
which no reports are received is larger than D_maxnorep. That was my
motivation to rename Dmaxnorep it to D_repsup, the duration during
which reports are suppressed. Does that make sense?
> I can see why you want the names for limits to be easily distinguished from the names of the variable. I'd simply use T_x and t_x [ie the data x is reported once the timer t_x has reached the value T_x]
>
I am fine with any distinction that makes clear what's a timer and
what's a value. Tx and Dx just seems simpler to me than T_x and t_x, but
this is not essential to me.
> I also suggest better names than 'mi' - it's hard to guess this means measurement interval, there are no prizes for as few characters as possible.
>
I don't object better names. I just proposed this as an improvement over
Tcalc which makes it hard to guess that it is related to the duration of
the measurement interval. There are so many calculations at different
nodes so that Tcalc does not seem to be specific enough for me ...
> I don't like your change of 'amount of traffic to be terminated' to 'Termination rate'. The latter suggests to me a continual process where you keep terminating this amount, whereas the former suggest a one-off process.
>
Well, I used to argue against this term for long time for exactly the
reasons you are stating. I just adopted it as it was consistently used
by Anna and others. As long as it is explained what it means I am fine
with it. I just think that we must name the quantity somehow to
facilitate talking about the mechanism.
> You deleted the phrase that the decision point MAY choose to terminate in one step or it MAY choose to spread over a longer period. I think it's better with this phrase.
> In general, I don't like the changes round the end of 3.3.2
>
The existing text was not clear enough for me, that's why I elaborated
this section.
> < sent PCN traffic (octets per second) for a specific ingress-
> egress-aggregate >>
> 'sent' is better than 'admitted'. I think it would be better to say something like:
> The PCN-ingress-node MUST provide an estimate of the current rate of PCN-traffic that is destined for this specific PCN-egress-node.
>
That's fine with me.
> < ... The procedure to provide the required information is out of the scope of this document.>>
> Ruediger, does this change pass your test?
>
I proposed this text to him in a private email and he replied that he
was ok with this phrasing.
> 5.4
> <>
> Better:
> The reference rates on each inward link, PCN-threshold-rate and PCN-excess-rate; see Section 2.
>
Not better, but equivalent ;-) I'm fine with this change.
Tom, can you take care of these changes to my corrections, please?
Kind regards,
Michael
> Thanks
> phil
>
>
>> -----Original Message-----
>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On
>> Behalf Of Michael Menth
>> Sent: 29 July 2010 20:15
>> Cc: pcn@ietf.org
>> Subject: Re: [PCN] PCN WGLC for the CL and SM edge behaviour drafts
>>
>>
>> Hi Tom, hi all,
>>
>> sorry for being late. I made some proposals for better
>> formulations in
>> some cases when I found a passage hard to understand. I also suggest
>> improved names for variables using the following idea:
>> Txyz: a timer name
>> Dxyz: the duration after which timer Txyz expires
>> I suggested more selfexplaining timer names for xyz
>> Suggest to change the variable name:
>> admission-decision-threshold (CLElimit) -> CLE limit (Lcle),
>> otherwise
>> this is confusing.
>>
>> I hope my comments are all well visible in the attached Word
>> file since
>> Word crashed twice while revising the doc.
>>
>> I also took care of Ruediger's comment and added appropriate text.
>>
>> Kind regards,
>>
>> Michael
>>
>>
>> Scott O. Bradner schrieb:
>>
>>> this starts a WGLC for
>>> "PCN Boundary Node Behaviour for the Controlled Load (CL) Mode
>>> of Operation" (draft-ietf-pcn-cl-edge-behaviour) and
>>> "PCN Boundary Node Behaviour for the Single Marking (SM) Mode
>>> of Operation" (draft-ietf-pcn-sm-edge-behaviour).
>>>
>>> comments to the list by July 24 please
>>>
>>> Scott
>>> _______________________________________________
>>> PCN mailing list
>>> PCN@ietf.org
>>> https://www.ietf.org/mailman/listinfo/pcn
>>>
>>>
>> --
>> PD Dr. habil. Michael Menth, Assistant Professor
>> University of Wuerzburg, Institute of Computer Science
>> Am Hubland, D-97074 Wuerzburg, Germany, room B206
>> phone: (+49)-931/31-86644 (new), fax: (+49)-931/31-86632
>> (new) mailto:menth@informatik.uni-wuerzburg.de
>> http://www3.informatik.uni-wuerzburg.de/research/ngn
>>
>>
>>
--
PD Dr. habil. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/31-86644 (new), fax: (+49)-931/31-86632 (new)
mailto:menth@informatik.uni-wuerzburg.de
http://www3.informatik.uni-wuerzburg.de/research/ngn
From Ruediger.Geib@telekom.de Wed Aug 4 00:36:36 2010
Return-Path:
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 D46FC3A69B9 for ; Wed, 4 Aug 2010 00:36:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.877
X-Spam-Level:
X-Spam-Status: No, score=-2.877 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1]
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 FzoYK4Dqo6Oc for ; Wed, 4 Aug 2010 00:36:35 -0700 (PDT)
Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 61E113A68C2 for ; Wed, 4 Aug 2010 00:36:31 -0700 (PDT)
Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail71.telekom.de with ESMTP; 04 Aug 2010 09:36:52 +0200
Received: from S4DE8PSAAQA.mitte.t-com.de ([10.151.229.12]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Aug 2010 09:36:52 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 4 Aug 2010 09:36:51 +0200
Message-ID: <151C164FE2E066418D8D44D0801543A5046A9808@S4DE8PSAAQA.mitte.t-com.de>
In-Reply-To: <4C22FF8FA5626046BF68899C06A0C9F71120F641E2@EMV67-UKRD.domain1.systemhost.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [PCN] PCN WGLC for the CL and SM edge behaviour drafts
Thread-Index: AcsvUmp4c3BoYIymTYWmDJjr8aN8ggDpV5xwACvrBkA=
References: <4C51D328.2020102@informatik.uni-wuerzburg.de> <4C22FF8FA5626046BF68899C06A0C9F71120F641E2@EMV67-UKRD.domain1.systemhost.net>
From:
To: ,
X-OriginalArrivalTime: 04 Aug 2010 07:36:52.0441 (UTC) FILETIME=[CE54CC90:01CB33A7]
Cc: pcn@ietf.org
Subject: Re: [PCN] PCN WGLC for the CL and SM edge behaviour drafts
X-BeenThere: pcn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PCN WG list
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 04 Aug 2010 07:36:37 -0000
Phil, Michael
[snip]
Michael: <>
Phil: Ruediger, does this change pass your test?
[snip]
Thanks, yes, that's sufficient.
Regards, Ruediger
> -----Original Message-----
> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On
> Behalf Of Michael Menth
> Sent: 29 July 2010 20:15
> Cc: pcn@ietf.org
> Subject: Re: [PCN] PCN WGLC for the CL and SM edge behaviour drafts
>
>
> Hi Tom, hi all,
>
> sorry for being late. I made some proposals for better
> formulations in
> some cases when I found a passage hard to understand. I also suggest
> improved names for variables using the following idea:
> Txyz: a timer name
> Dxyz: the duration after which timer Txyz expires
> I suggested more selfexplaining timer names for xyz
> Suggest to change the variable name:
> admission-decision-threshold (CLElimit) -> CLE limit (Lcle),
> otherwise
> this is confusing.
>
> I hope my comments are all well visible in the attached Word
> file since
> Word crashed twice while revising the doc.
>
> I also took care of Ruediger's comment and added appropriate text.
>
> Kind regards,
>
> Michael
>
>
> Scott O. Bradner schrieb:
> > this starts a WGLC for
> > "PCN Boundary Node Behaviour for the Controlled Load (CL) Mode
> > of Operation" (draft-ietf-pcn-cl-edge-behaviour) and
> > "PCN Boundary Node Behaviour for the Single Marking (SM) Mode
> > of Operation" (draft-ietf-pcn-sm-edge-behaviour).
> >
> > comments to the list by July 24 please
> >
> > Scott
> > _______________________________________________
> > PCN mailing list
> > PCN@ietf.org
> > https://www.ietf.org/mailman/listinfo/pcn
> >
>
> --
> PD Dr. habil. Michael Menth, Assistant Professor
> University of Wuerzburg, Institute of Computer Science
> Am Hubland, D-97074 Wuerzburg, Germany, room B206
> phone: (+49)-931/31-86644 (new), fax: (+49)-931/31-86632
> (new) mailto:menth@informatik.uni-wuerzburg.de
> http://www3.informatik.uni-wuerzburg.de/research/ngn
>
>
_______________________________________________
PCN mailing list
PCN@ietf.org
https://www.ietf.org/mailman/listinfo/pcn
From Ruediger.Geib@telekom.de Fri Aug 20 01:22:12 2010
Return-Path:
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 6AB403A6843 for ; Fri, 20 Aug 2010 01:22:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.438
X-Spam-Level:
X-Spam-Status: No, score=-1.438 tagged_above=-999 required=5 tests=[AWL=-0.789, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1]
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 BCOq7FjdESPO for ; Fri, 20 Aug 2010 01:22:11 -0700 (PDT)
Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 70C8B3A683C for ; Fri, 20 Aug 2010 01:22:09 -0700 (PDT)
Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail71.telekom.de with ESMTP; 20 Aug 2010 10:22:41 +0200
Received: from S4DE8PSAAQA.mitte.t-com.de ([10.151.229.12]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Fri, 20 Aug 2010 10:22:41 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 20 Aug 2010 10:22:39 +0200
Message-ID: <151C164FE2E066418D8D44D0801543A50487BA04@S4DE8PSAAQA.mitte.t-com.de>
In-Reply-To: <4C51D328.2020102@informatik.uni-wuerzburg.de>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [PCN] PCN WGLC for the CL and SM edge behaviour drafts
Thread-Index: AcsvUne9TB/GsOU0Snq6LQn4DZ8dcQIMlezg
References: <20100710133056.DE5561AFCCE@newdev.eecs.harvard.edu> <4C51D328.2020102@informatik.uni-wuerzburg.de>
From:
To:
X-OriginalArrivalTime: 20 Aug 2010 08:22:41.0445 (UTC) FILETIME=[DB798550:01CB4040]
Cc: pcn@ietf.org
Subject: Re: [PCN] PCN WGLC for the CL and SM edge behaviour drafts
X-BeenThere: pcn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PCN WG list
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 20 Aug 2010 08:22:12 -0000
Hello Michael,
one additional remark,
On your question on 3.3 I'd suggest a simple answer:
If only Termination is active, new flows are addmitted by default until =
termination state is reached. Then some traffic may have to be =
terminated and new traffic shouldn't be admitted. Details on such an =
operational regime are out of scope of this document.
Would that make sense?
Regards,
Ruediger=20
-----Original Message-----
From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of =
Michael Menth
Sent: Thursday, July 29, 2010 9:15 PM
Cc: pcn@ietf.org
Subject: Re: [PCN] PCN WGLC for the CL and SM edge behaviour drafts
Hi Tom, hi all,
sorry for being late. I made some proposals for better formulations in=20
some cases when I found a passage hard to understand. I also suggest=20
improved names for variables using the following idea:
Txyz: a timer name
Dxyz: the duration after which timer Txyz expires
I suggested more selfexplaining timer names for xyz
Suggest to change the variable name:
admission-decision-threshold (CLElimit) -> CLE limit (Lcle), otherwise=20
this is confusing.
I hope my comments are all well visible in the attached Word file since=20
Word crashed twice while revising the doc.
I also took care of Ruediger's comment and added appropriate text.
Kind regards,
Michael
Scott O. Bradner schrieb:
> this starts a WGLC for=20
> "PCN Boundary Node Behaviour for the Controlled Load (CL) Mode=20
> of Operation" (draft-ietf-pcn-cl-edge-behaviour) and
> "PCN Boundary Node Behaviour for the Single Marking (SM) Mode=20
> of Operation" (draft-ietf-pcn-sm-edge-behaviour).
>
> comments to the list by July 24 please
>
> Scott
> _______________________________________________
> PCN mailing list
> PCN@ietf.org
> https://www.ietf.org/mailman/listinfo/pcn
> =20
--=20
PD Dr. habil. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/31-86644 (new), fax: (+49)-931/31-86632 (new)
mailto:menth@informatik.uni-wuerzburg.de
http://www3.informatik.uni-wuerzburg.de/research/ngn
From menth@informatik.uni-wuerzburg.de Fri Aug 20 01:37:03 2010
Return-Path:
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 CC8AB3A67B7 for ; Fri, 20 Aug 2010 01:37:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level:
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
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 0tPp++PvL58E for ; Fri, 20 Aug 2010 01:37:02 -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 846873A6841 for ; Fri, 20 Aug 2010 01:37:02 -0700 (PDT)
Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id D94F12195B; Fri, 20 Aug 2010 10:37:33 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id D694F49019; Fri, 20 Aug 2010 10:37:33 +0200 (CEST)
X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de
Received: from [192.168.1.2] (wrzb-4d004bf6.pool.mediaWays.net [77.0.75.246]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTPSA id 9BAD65CDE0; Fri, 20 Aug 2010 10:37:33 +0200 (CEST)
Message-ID: <4C6E3EA7.9030405@informatik.uni-wuerzburg.de>
Date: Fri, 20 Aug 2010 10:36:55 +0200
From: Michael Menth
Organization: University of Wuerzburg
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Ruediger.Geib@telekom.de
References: <20100710133056.DE5561AFCCE@newdev.eecs.harvard.edu> <4C51D328.2020102@informatik.uni-wuerzburg.de> <151C164FE2E066418D8D44D0801543A50487BA04@S4DE8PSAAQA.mitte.t-com.de>
In-Reply-To: <151C164FE2E066418D8D44D0801543A50487BA04@S4DE8PSAAQA.mitte.t-com.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: pcn@ietf.org
Subject: Re: [PCN] PCN WGLC for the CL and SM edge behaviour drafts
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
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 20 Aug 2010 08:37:03 -0000
Hi Rüdiger,
I think your email is regarding this text in the draft:
Operators may choose to deploy just flow admission, or just flow
termination, or both. The Decision Point MUST implement both
mechanisms, but configurable options MUST be provided to activate or
deactivate PCN-based flow admission and flow termination
independently of each other at a given Decision Point.
Ruediger.Geib@telekom.de schrieb:
> On your question on 3.3 I'd suggest a simple answer:
>
> If only Termination is active, new flows are addmitted by default until termination state is reached. Then some traffic may have to be terminated and new traffic shouldn't be admitted. Details on such an operational regime are out of scope of this document.
> Would that make sense?
>
How can "shouldn't be admitted" be enforced? I believe flow termination
requires admission control to be implemented.
Does anybody have a clear vision how flow termination without admission
control is feasible?
Regards,
Michael
--
PD Dr. habil. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/31-86644 (new), fax: (+49)-931/31-86632 (new)
mailto:menth@informatik.uni-wuerzburg.de
http://www3.informatik.uni-wuerzburg.de/research/ngn
From Ruediger.Geib@telekom.de Fri Aug 20 01:46:16 2010
Return-Path:
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 2B3753A68A9 for ; Fri, 20 Aug 2010 01:46:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.58
X-Spam-Level:
X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.669, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1]
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 j8LRy3A0c8nP for ; Fri, 20 Aug 2010 01:46:15 -0700 (PDT)
Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id ECEC83A67A5 for ; Fri, 20 Aug 2010 01:46:14 -0700 (PDT)
Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail71.telekom.de with ESMTP; 20 Aug 2010 10:46:48 +0200
Received: from S4DE8PSAAQA.mitte.t-com.de ([10.151.229.12]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Fri, 20 Aug 2010 10:46:48 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 20 Aug 2010 10:46:47 +0200
Message-ID: <151C164FE2E066418D8D44D0801543A50487BA7F@S4DE8PSAAQA.mitte.t-com.de>
In-Reply-To: <151C164FE2E066418D8D44D0801543A50487BA04@S4DE8PSAAQA.mitte.t-com.de>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: draft-menth-pcn-implicit-probing
Thread-Index: AcsvUne9TB/GsOU0Snq6LQn4DZ8dcQIMlezgAi98GlA=
References: <20100710133056.DE5561AFCCE@newdev.eecs.harvard.edu><4C51D328.2020102@informatik.uni-wuerzburg.de> <151C164FE2E066418D8D44D0801543A50487BA04@S4DE8PSAAQA.mitte.t-com.de>
From:
To:
X-OriginalArrivalTime: 20 Aug 2010 08:46:48.0476 (UTC) FILETIME=[39F8EDC0:01CB4044]
Cc: pcn@ietf.org
Subject: [PCN] draft-menth-pcn-implicit-probing
X-BeenThere: pcn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PCN WG list
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 20 Aug 2010 08:46:16 -0000
Hello Michael,
during the Maastricht meeting we agreed to avoid the term "implicit =
probing". To me, probing would mean transmitting packets for the only =
purpose of probing (i.e. they carry no other information or have any =
other purpose then probing). What the draft proposes however is to mark =
one (or more) regular signaling packets which are transmitted along the =
same path as a PCN data packet with the same PCN code point as a data =
packet.=20
To me "PCN marked signaling" seems a proper definition of what we =
propose. Are there objections or better suggestions on the idea?=20
Regards,
Ruediger
From menth@informatik.uni-wuerzburg.de Fri Aug 20 01:49:58 2010
Return-Path:
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 4F9183A68E0 for ; Fri, 20 Aug 2010 01:49:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level:
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
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 xCxMBXidodN9 for ; Fri, 20 Aug 2010 01:49:57 -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 221483A6849 for ; Fri, 20 Aug 2010 01:49:57 -0700 (PDT)
Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 844615AC95; Fri, 20 Aug 2010 10:50:31 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 809EB5AC8D; Fri, 20 Aug 2010 10:50:31 +0200 (CEST)
X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de
Received: from [192.168.1.2] (wrzb-4d004bf6.pool.mediaWays.net [77.0.75.246]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTPSA id 446EE5CC8C; Fri, 20 Aug 2010 10:50:31 +0200 (CEST)
Message-ID: <4C6E41AC.1000901@informatik.uni-wuerzburg.de>
Date: Fri, 20 Aug 2010 10:49:48 +0200
From: Michael Menth
Organization: University of Wuerzburg
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Ruediger.Geib@telekom.de
References: <20100710133056.DE5561AFCCE@newdev.eecs.harvard.edu><4C51D328.2020102@informatik.uni-wuerzburg.de> <151C164FE2E066418D8D44D0801543A50487BA04@S4DE8PSAAQA.mitte.t-com.de> <151C164FE2E066418D8D44D0801543A50487BA7F@S4DE8PSAAQA.mitte.t-com.de>
In-Reply-To: <151C164FE2E066418D8D44D0801543A50487BA7F@S4DE8PSAAQA.mitte.t-com.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: pcn@ietf.org
Subject: Re: [PCN] draft-menth-pcn-implicit-probing
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
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 20 Aug 2010 08:49:58 -0000
Hi Rüdiger,
yes, that's correct. We need a different name. I currently work with
"signalling-inferred admission control". I am open for improvements.
Best wishes,
Michael
Ruediger.Geib@telekom.de schrieb:
> Hello Michael,
>
> during the Maastricht meeting we agreed to avoid the term "implicit probing". To me, probing would mean transmitting packets for the only purpose of probing (i.e. they carry no other information or have any other purpose then probing). What the draft proposes however is to mark one (or more) regular signaling packets which are transmitted along the same path as a PCN data packet with the same PCN code point as a data packet.
>
> To me "PCN marked signaling" seems a proper definition of what we propose. Are there objections or better suggestions on the idea?
>
> Regards,
>
> Ruediger
>
--
PD Dr. habil. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/31-86644 (new), fax: (+49)-931/31-86632 (new)
mailto:menth@informatik.uni-wuerzburg.de
http://www3.informatik.uni-wuerzburg.de/research/ngn
From Ruediger.Geib@telekom.de Fri Aug 20 02:38:28 2010
Return-Path:
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 307843A68E3 for ; Fri, 20 Aug 2010 02:38:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level:
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1]
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 gaVNJo5aCZ1c for ; Fri, 20 Aug 2010 02:38:23 -0700 (PDT)
Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id 303FD3A682F for ; Fri, 20 Aug 2010 02:38:20 -0700 (PDT)
Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail31.telekom.de with ESMTP; 20 Aug 2010 11:38:50 +0200
Received: from S4DE8PSAAQA.mitte.t-com.de ([10.151.229.12]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Fri, 20 Aug 2010 11:38:49 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 20 Aug 2010 11:38:48 +0200
Message-ID: <151C164FE2E066418D8D44D0801543A50487BB80@S4DE8PSAAQA.mitte.t-com.de>
In-Reply-To: <4C6E41AC.1000901@informatik.uni-wuerzburg.de>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: draft-menth-pcn-implicit-probing
Thread-Index: ActARL/r9ULKceE8T02eQPkeiTIYlgABodZA
References: <20100710133056.DE5561AFCCE@newdev.eecs.harvard.edu><4C51D328.2020102@informatik.uni-wuerzburg.de> <151C164FE2E066418D8D44D0801543A50487BA04@S4DE8PSAAQA.mitte.t-com.de> <151C164FE2E066418D8D44D0801543A50487BA7F@S4DE8PSAAQA.mitte.t-com.de> <4C6E41AC.1000901@informatik.uni-wuerzburg.de>
From:
To:
X-OriginalArrivalTime: 20 Aug 2010 09:38:49.0711 (UTC) FILETIME=[7E5F97F0:01CB404B]
Cc: pcn@ietf.org
Subject: Re: [PCN] draft-menth-pcn-implicit-probing
X-BeenThere: pcn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PCN WG list
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 20 Aug 2010 09:38:28 -0000
Hi Michael,
>>>I currently work with=20
>>>"signalling-inferred admission control". I am open for improvements.
If others don't express preferences, we can stick with that one too.
Regards, Ruediger
Ruediger.Geib@telekom.de schrieb:
> Hello Michael,
>
> during the Maastricht meeting we agreed to avoid the term "implicit =
probing". To me, probing would mean transmitting packets for the only =
purpose of probing (i.e. they carry no other information or have any =
other purpose then probing). What the draft proposes however is to mark =
one (or more) regular signaling packets which are transmitted along the =
same path as a PCN data packet with the same PCN code point as a data =
packet.=20
>
> To me "PCN marked signaling" seems a proper definition of what we =
propose. Are there objections or better suggestions on the idea?=20
>
> Regards,
>
> Ruediger
> =20
--=20
PD Dr. habil. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/31-86644 (new), fax: (+49)-931/31-86632 (new)
mailto:menth@informatik.uni-wuerzburg.de
http://www3.informatik.uni-wuerzburg.de/research/ngn
From tom111.taylor@bell.net Fri Aug 20 08:55:01 2010
Return-Path:
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 5BD613A6ACC for ; Fri, 20 Aug 2010 08:55:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.623
X-Spam-Level:
X-Spam-Status: No, score=-99.623 tagged_above=-999 required=5 tests=[AWL=-0.427, BAYES_50=0.001, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100]
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 oY3iIQNsO-Pk for ; Fri, 20 Aug 2010 08:55:00 -0700 (PDT)
Received: from blu0-omc1-s1.blu0.hotmail.com (blu0-omc1-s1.blu0.hotmail.com [65.55.116.12]) by core3.amsl.com (Postfix) with ESMTP id 460273A6AB9 for ; Fri, 20 Aug 2010 08:55:00 -0700 (PDT)
Received: from BLU0-SMTP33 ([65.55.116.9]) by blu0-omc1-s1.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 20 Aug 2010 08:55:34 -0700
X-Originating-IP: [69.158.64.160]
X-Originating-Email: [tom111.taylor@bell.net]
Message-ID:
Received: from [192.168.2.11] ([69.158.64.160]) by BLU0-SMTP33.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 20 Aug 2010 08:55:34 -0700
Date: Fri, 20 Aug 2010 11:55:28 -0400
From: Tom Taylor
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: menth@informatik.uni-wuerzburg.de
References: <20100710133056.DE5561AFCCE@newdev.eecs.harvard.edu> <4C51D328.2020102@informatik.uni-wuerzburg.de> <151C164FE2E066418D8D44D0801543A50487BA04@S4DE8PSAAQA.mitte.t-com.de> <4C6E3EA7.9030405@informatik.uni-wuerzburg.de>
In-Reply-To: <4C6E3EA7.9030405@informatik.uni-wuerzburg.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-OriginalArrivalTime: 20 Aug 2010 15:55:34.0451 (UTC) FILETIME=[1FD93030:01CB4080]
Cc: pcn@ietf.org
Subject: Re: [PCN] PCN WGLC for the CL and SM edge behaviour drafts
X-BeenThere: pcn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PCN WG list
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 20 Aug 2010 15:55:01 -0000
Below, following Michael's query.
On 20/08/2010 4:36 AM, Michael Menth wrote:
> Hi Rüdiger,
>
> I think your email is regarding this text in the draft:
>
> Operators may choose to deploy just flow admission, or just flow
> termination, or both. The Decision Point MUST implement both
> mechanisms, but configurable options MUST be provided to activate or
> deactivate PCN-based flow admission and flow termination
> independently of each other at a given Decision Point.
>
>
>
> Ruediger.Geib@telekom.de schrieb:
>> On your question on 3.3 I'd suggest a simple answer:
>>
>> If only Termination is active, new flows are addmitted by default until
>> termination state is reached. Then some traffic may have to be terminated and
>> new traffic shouldn't be admitted. Details on such an operational regime are
>> out of scope of this document.
>> Would that make sense?
>
> How can "shouldn't be admitted" be enforced? I believe flow termination requires
> admission control to be implemented.
>
> Does anybody have a clear vision how flow termination without admission control
> is feasible?
>
> Regards,
>
> Michael
>
[PTT] My own feeling is we should stick strictly to how flow termination works
and leave it up to the operator to sort out the question of admission. I think
that's what Ruediger was trying to say, and I would phrase it like this:
If flow termination is enabled but flow admission is not, flow termination
operates as specified in this document. Logically, some system of flow admission
control is needed to keep new flows from being admitted to an
ingress-egress-aggregate while flows are being terminated on that aggregate, but
the operation of such a system is out of scope of this document and depends on
local arrangements.
From menth@informatik.uni-wuerzburg.de Fri Aug 20 12:46:06 2010
Return-Path:
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 449253A694D for ; Fri, 20 Aug 2010 12:46:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level:
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
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 zicuJOmOYiIm for ; Fri, 20 Aug 2010 12:46:05 -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 CBEB03A69C5 for ; Fri, 20 Aug 2010 12:46:04 -0700 (PDT)
Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 640445AD6E; Fri, 20 Aug 2010 21:46:38 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 5D9895ACA8; Fri, 20 Aug 2010 21:46:38 +0200 (CEST)
X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de
Received: from [192.168.1.2] (wrzb-4d004bf6.pool.mediaWays.net [77.0.75.246]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTPSA id 160925CDE2; Fri, 20 Aug 2010 21:46:38 +0200 (CEST)
Message-ID: <4C6EDB9F.2060902@informatik.uni-wuerzburg.de>
Date: Fri, 20 Aug 2010 21:46:39 +0200
From: Michael Menth
Organization: University of Wuerzburg
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Tom Taylor
References: <20100710133056.DE5561AFCCE@newdev.eecs.harvard.edu> <4C51D328.2020102@informatik.uni-wuerzburg.de> <151C164FE2E066418D8D44D0801543A50487BA04@S4DE8PSAAQA.mitte.t-com.de> <4C6E3EA7.9030405@informatik.uni-wuerzburg.de>
In-Reply-To:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: pcn@ietf.org
Subject: Re: [PCN] PCN WGLC for the CL and SM edge behaviour drafts
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
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 20 Aug 2010 19:46:06 -0000
Tom Taylor schrieb:
> Below, following Michael's query.
>
> On 20/08/2010 4:36 AM, Michael Menth wrote:
>> Hi Rüdiger,
>>
>> I think your email is regarding this text in the draft:
>>
>> Operators may choose to deploy just flow admission, or just flow
>> termination, or both. The Decision Point MUST implement both
>> mechanisms, but configurable options MUST be provided to activate or
>> deactivate PCN-based flow admission and flow termination
>> independently of each other at a given Decision Point.
>>
>>
>>
>> Ruediger.Geib@telekom.de schrieb:
>>> On your question on 3.3 I'd suggest a simple answer:
>>>
>>> If only Termination is active, new flows are addmitted by default until
>>> termination state is reached. Then some traffic may have to be
>>> terminated and
>>> new traffic shouldn't be admitted. Details on such an operational
>>> regime are
>>> out of scope of this document.
>>> Would that make sense?
>>
>> How can "shouldn't be admitted" be enforced? I believe flow
>> termination requires
>> admission control to be implemented.
>>
>> Does anybody have a clear vision how flow termination without
>> admission control
>> is feasible?
>>
>> Regards,
>>
>> Michael
>>
> [PTT] My own feeling is we should stick strictly to how flow
> termination works and leave it up to the operator to sort out the
> question of admission. I think that's what Ruediger was trying to say,
> and I would phrase it like this:
>
> If flow termination is enabled but flow admission is not, flow
> termination operates as specified in this document. Logically, some
> system of flow admission control is needed to keep new flows from
> being admitted to an ingress-egress-aggregate while flows are being
> terminated on that aggregate, but the operation of such a system is
> out of scope of this document and depends on local arrangements.
This phrase is somehow a contradiction: "but flow admission is not
[enabled]" & "some system of flow admission control is needed" ...
Tom, your sentence basically says that PCN-based flow termination can be
done with some other sort of admission control which does not need to be
based on PCN. That is something I agree with. What I dislike is a strong
statement that flow termination can be used without (any kind of)
admission control. Can't we just say that PCN-based AC can be used on
its own or in combination with flow termination? Why is this other
statement (flow termination alone can be used) necessary if nobody knows
how to implement it now? Isn't it enough to not forbid it?
Regards,
Michael
--
PD Dr. habil. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/31-86644 (new), fax: (+49)-931/31-86632 (new)
mailto:menth@informatik.uni-wuerzburg.de
http://www3.informatik.uni-wuerzburg.de/research/ngn
From tom111.taylor@bell.net Tue Aug 24 06:29:26 2010
Return-Path:
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 D31403A69D1 for ; Tue, 24 Aug 2010 06:29:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.555
X-Spam-Level:
X-Spam-Status: No, score=-99.555 tagged_above=-999 required=5 tests=[AWL=-0.359, BAYES_50=0.001, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100]
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 N4eBLbU2lk-c for ; Tue, 24 Aug 2010 06:29:24 -0700 (PDT)
Received: from blu0-omc1-s5.blu0.hotmail.com (blu0-omc1-s5.blu0.hotmail.com [65.55.116.16]) by core3.amsl.com (Postfix) with ESMTP id 7E2593A681A for ; Tue, 24 Aug 2010 06:29:23 -0700 (PDT)
Received: from BLU0-SMTP93 ([65.55.116.9]) by blu0-omc1-s5.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 Aug 2010 06:29:56 -0700
X-Originating-IP: [69.158.67.9]
X-Originating-Email: [tom111.taylor@bell.net]
Message-ID:
Received: from [192.168.2.11] ([69.158.67.9]) by BLU0-SMTP93.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 Aug 2010 06:29:55 -0700
Date: Tue, 24 Aug 2010 09:29:53 -0400
From: Tom Taylor
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: pcn
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 24 Aug 2010 13:29:56.0000 (UTC) FILETIME=[70FA6200:01CB4390]
Subject: [PCN] Summary of technical points -- PCN WGLC for the CL and SM edge behaviour drafts
X-BeenThere: pcn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PCN WG list
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 24 Aug 2010 13:29:26 -0000
It's time I rounded up all the comments and responded to them. Technical
comments in this E-mail, editorial in the next one. Thanks for the reviews.
1) Phil, 12/07/2010, smoothing of CLE:
Asked whether smoothing of the CLE is now completely done away with. Aside from
the implicit smoothing due to the fact that the measurements are accumulated
over an interval, that is correct. Remember that your original concept was a
packet-by-packet recomputation of the CLE, and in that case smoothing was
essential. It is no longer necessary.
-----
2) Discussion of an additional thresholding parameter for report suppression
(16-18/07/2010) (Tom, Toby, Georgios, Michael, Fortune):
Argument on one side was that the difference in signalling traffic between a
zero and non-zero CLE reporting threshold would be tiny. Argument on the other
that even so, for the centralized decision point it could be worthwhile.
Resolution: add the report suppression threshold parameter, default value zero.
Parameter has effect only if report suppression is activated in the first place.
-----
3) Ruediger, 26/07/2010, concluded 04/08/2010, how to identify an
ingress-egress-aggregate:
Change the existing text to say this is out of scope of the existing document.
-----
4) Michael's marked-up version, 29/07/2010, reporting of flow identifiers:
Report only the flows that have been excess-marked recently. Agreed.
-----
5) Michael's marked-up version, 29/07/2010, requirement for mapping information
at the Decision Point:
Indicated that the Decision Point has to know how to map packets received at the
egress node to individual ingress-egress-aggregates. I don't see why this is so.
-----
6) Michael's marked-up version, 29/07/2010, and follow-up notes (Ruediger,
Michael, Tom) 20/08/2010, how a system works with PCN-based flow termination but
no PCN-based flow admission:
Proposed resolution: tighten up the language proposed I proposed to provide a
clear distinction between PCN-based and non-PCN-based flow admission, as follows:
"If PCN-based flow termination is enabled but PCN-based flow admission is not,
flow termination operates as specified in this document. Logically, some other
system of flow admission control is needed to keep new flows from being admitted
to an ingress-egress-aggregate while flows are being terminated on that
aggregate, but the operation of such a system is out of scope of this document
and depends on local arrangements."
-----
Tom Taylor
From menth@informatik.uni-wuerzburg.de Tue Aug 24 07:12:19 2010
Return-Path:
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 B808C3A6843 for ; Tue, 24 Aug 2010 07:12:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.949
X-Spam-Level:
X-Spam-Status: No, score=-4.949 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 S--JDMArbmES for ; Tue, 24 Aug 2010 07:12:17 -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 5DA983A6A47 for ; Tue, 24 Aug 2010 07:12:16 -0700 (PDT)
Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id A2F3E5AD42; Tue, 24 Aug 2010 16:12:46 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 962705ACF3; Tue, 24 Aug 2010 16:12:46 +0200 (CEST)
X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de
Received: from [192.168.1.2] (wrzb-4d0050b6.pool.mediaWays.net [77.0.80.182]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTPSA id CE4DB5CCD0; Tue, 24 Aug 2010 16:12:45 +0200 (CEST)
Message-ID: <4C73D35A.2060801@informatik.uni-wuerzburg.de>
Date: Tue, 24 Aug 2010 16:12:42 +0200
From: Michael Menth
Organization: University of Wuerzburg
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: Tom Taylor
References:
In-Reply-To:
Content-Type: multipart/alternative; boundary="------------010303090203010507020904"
Cc: pcn
Subject: Re: [PCN] Summary of technical points -- PCN WGLC for the CL and SM edge behaviour drafts
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
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 24 Aug 2010 14:12:19 -0000
This is a multi-part message in MIME format.
--------------010303090203010507020904
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Hi Tom,
Am 24.08.2010 15:29, schrieb Tom Taylor:
> It's time I rounded up all the comments and responded to them.
> Technical comments in this E-mail, editorial in the next one. Thanks
> for the reviews.
>
> 1) Phil, 12/07/2010, smoothing of CLE:
>
> Asked whether smoothing of the CLE is now completely done away with.
> Aside from the implicit smoothing due to the fact that the
> measurements are accumulated over an interval, that is correct.
> Remember that your original concept was a packet-by-packet
> recomputation of the CLE, and in that case smoothing was essential. It
> is no longer necessary.
> -----
>
> 2) Discussion of an additional thresholding parameter for report
> suppression (16-18/07/2010) (Tom, Toby, Georgios, Michael, Fortune):
>
> Argument on one side was that the difference in signalling traffic
> between a zero and non-zero CLE reporting threshold would be tiny.
> Argument on the other that even so, for the centralized decision point
> it could be worthwhile. Resolution: add the report suppression
> threshold parameter, default value zero. Parameter has effect only if
> report suppression is activated in the first place.
> -----
>
> 3) Ruediger, 26/07/2010, concluded 04/08/2010, how to identify an
> ingress-egress-aggregate:
>
> Change the existing text to say this is out of scope of the existing
> document.
> -----
>
> 4) Michael's marked-up version, 29/07/2010, reporting of flow
> identifiers:
>
> Report only the flows that have been excess-marked recently. Agreed.
> -----
>
> 5) Michael's marked-up version, 29/07/2010, requirement for mapping
> information at the Decision Point:
>
> Indicated that the Decision Point has to know how to map packets
> received at the egress node to individual ingress-egress-aggregates. I
> don't see why this is so.
o The information needed to map PCN-packets received by the
PCN-egress-node to the correct ingress-egress-aggregate.
Of course this text does not belong to the parameters of the decision
point but to the parameters of the egress node. The egress node needs to
know how to map the packets to IEAs. The proposed text is somewhat
clearer than what's in the draft so far:
o The information needed to distinguish PCN traffic belonging to a
given ingress-egress-aggregate.
HTH,
Michael
> -----
>
> 6) Michael's marked-up version, 29/07/2010, and follow-up notes
> (Ruediger, Michael, Tom) 20/08/2010, how a system works with PCN-based
> flow termination but no PCN-based flow admission:
>
> Proposed resolution: tighten up the language proposed I proposed to
> provide a clear distinction between PCN-based and non-PCN-based flow
> admission, as follows:
>
> "If PCN-based flow termination is enabled but PCN-based flow admission
> is not, flow termination operates as specified in this document.
> Logically, some other system of flow admission control is needed to
> keep new flows from being admitted to an ingress-egress-aggregate
> while flows are being terminated on that aggregate, but the operation
> of such a system is out of scope of this document and depends on local
> arrangements."
> -----
>
> Tom Taylor
> _______________________________________________
> PCN mailing list
> PCN@ietf.org
> https://www.ietf.org/mailman/listinfo/pcn
--
PD Dr. habil. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/31-86644 (new), fax: (+49)-931/31-86632 (new)
mailto:menth@informatik.uni-wuerzburg.de
http://www3.informatik.uni-wuerzburg.de/research/ngn
--------------010303090203010507020904
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Hi Tom,
Am 24.08.2010 15:29, schrieb Tom Taylor:
It's time I rounded up all the comments and responded
to them. Technical comments in this E-mail, editorial in the next
one. Thanks for the reviews.
1) Phil, 12/07/2010, smoothing of CLE:
Asked whether smoothing of the CLE is now completely done away
with. Aside from the implicit smoothing due to the fact that the
measurements are accumulated over an interval, that is correct.
Remember that your original concept was a packet-by-packet
recomputation of the CLE, and in that case smoothing was
essential. It is no longer necessary.
-----
2) Discussion of an additional thresholding parameter for report
suppression (16-18/07/2010) (Tom, Toby, Georgios, Michael,
Fortune):
Argument on one side was that the difference in signalling traffic
between a zero and non-zero CLE reporting threshold would be tiny.
Argument on the other that even so, for the centralized decision
point it could be worthwhile. Resolution: add the report
suppression threshold parameter, default value zero. Parameter has
effect only if report suppression is activated in the first place.
-----
3) Ruediger, 26/07/2010, concluded 04/08/2010, how to identify an
ingress-egress-aggregate:
Change the existing text to say this is out of scope of the
existing document.
-----
4) Michael's marked-up version, 29/07/2010, reporting of flow
identifiers:
Report only the flows that have been excess-marked recently.
Agreed.
-----
5) Michael's marked-up version, 29/07/2010, requirement for
mapping information at the Decision Point:
Indicated that the Decision Point has to know how to map packets
received at the egress node to individual
ingress-egress-aggregates. I don't see why this is so.
oThe information needed to map PCN-packets
received by the PCN-egress-node to the correct
ingress-egress-aggregate.
Of course this text does not belong to the parameters of the
decision point but to the parameters of the egress node. The
egress node needs to know how to map the packets to IEAs. The
proposed text is somewhat clearer than what's in the draft so far:
oThe information needed to distinguish PCN
traffic belonging to a
given
ingress-egress-aggregate.
HTH,
Michael
-----
6) Michael's marked-up version, 29/07/2010, and follow-up notes
(Ruediger, Michael, Tom) 20/08/2010, how a system works with
PCN-based flow termination but no PCN-based flow admission:
Proposed resolution: tighten up the language proposed I proposed
to provide a clear distinction between PCN-based and non-PCN-based
flow admission, as follows:
"If PCN-based flow termination is enabled but PCN-based flow
admission is not, flow termination operates as specified in this
document. Logically, some other system of flow admission control
is needed to keep new flows from being admitted to an
ingress-egress-aggregate while flows are being terminated on that
aggregate, but the operation of such a system is out of scope of
this document and depends on local arrangements."
-----
--------------010303090203010507020904--
From tom111.taylor@bell.net Tue Aug 24 07:32:24 2010
Return-Path:
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 B57443A69FA for ; Tue, 24 Aug 2010 07:32:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.537
X-Spam-Level:
X-Spam-Status: No, score=-99.537 tagged_above=-999 required=5 tests=[AWL=-0.341, BAYES_50=0.001, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100]
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 amTH9tiiZOI0 for ; Tue, 24 Aug 2010 07:32:24 -0700 (PDT)
Received: from blu0-omc1-s4.blu0.hotmail.com (blu0-omc1-s4.blu0.hotmail.com [65.55.116.15]) by core3.amsl.com (Postfix) with ESMTP id C743C3A6AFD for ; Tue, 24 Aug 2010 07:32:23 -0700 (PDT)
Received: from BLU0-SMTP15 ([65.55.116.8]) by blu0-omc1-s4.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 Aug 2010 07:32:56 -0700
X-Originating-IP: [69.158.67.9]
X-Originating-Email: [tom111.taylor@bell.net]
Message-ID:
Received: from [192.168.2.11] ([69.158.67.9]) by BLU0-SMTP15.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 Aug 2010 07:32:56 -0700
Date: Tue, 24 Aug 2010 10:32:53 -0400
From: Tom Taylor
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: pcn , Scott Bradner , Steven Blake
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 24 Aug 2010 14:32:56.0492 (UTC) FILETIME=[3E53AEC0:01CB4399]
Subject: [PCN] Editorial issues -- PCN WGLC for the CL and SM edge behaviour drafts
X-BeenThere: pcn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PCN WG list
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 24 Aug 2010 14:32:24 -0000
I started to write a note on the more general editorial issues, but decided it
would be simpler just to work these through privately with Michael and Philip,
if that is agreeable to the list.
Aside from the postings to the list, I received an updated reference from
Daisuke that will replace his current one in the document.
Chairs, may I submit updated drafts when the editorial issues are ironed out?
Tom Taylor
From sob@harvard.edu Tue Aug 24 07:35:29 2010
Return-Path:
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 920423A6A2E for ; Tue, 24 Aug 2010 07:35:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.912
X-Spam-Level:
X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[AWL=0.687, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 SjG4kguZq4In for ; Tue, 24 Aug 2010 07:35:22 -0700 (PDT)
Received: from newdev.eecs.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by core3.amsl.com (Postfix) with ESMTP id 53E8A3A6B49 for ; Tue, 24 Aug 2010 07:35:19 -0700 (PDT)
Received: by newdev.eecs.harvard.edu (Postfix, from userid 501) id 1A9352B8E6B; Tue, 24 Aug 2010 10:35:49 -0400 (EDT)
To: pcn@ietf.org, slblake@petri-meat.com, sob@harvard.edu, tom111.taylor@bell.net
In-Reply-To:
Message-Id: <20100824143549.1A9352B8E6B@newdev.eecs.harvard.edu>
Date: Tue, 24 Aug 2010 10:35:49 -0400 (EDT)
From: sob@harvard.edu (Scott O. Bradner)
Subject: Re: [PCN] Editorial issues -- PCN WGLC for the CL and SM edge behaviour drafts
X-BeenThere: pcn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PCN WG list
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 24 Aug 2010 14:35:29 -0000
> Chairs, may I submit updated drafts when the editorial issues are ironed out?
please do
Scott
From tom111.taylor@bell.net Thu Aug 26 08:00:57 2010
Return-Path:
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 C9A673A69E0 for ; Thu, 26 Aug 2010 08:00:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.993
X-Spam-Level:
X-Spam-Status: No, score=-98.993 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_50=0.001, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100]
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 9OS8NQtrAg1G for ; Thu, 26 Aug 2010 08:00:57 -0700 (PDT)
Received: from blu0-omc1-s30.blu0.hotmail.com (blu0-omc1-s30.blu0.hotmail.com [65.55.116.41]) by core3.amsl.com (Postfix) with ESMTP id D6B963A697D for ; Thu, 26 Aug 2010 08:00:56 -0700 (PDT)
Received: from BLU0-SMTP70 ([65.55.116.7]) by blu0-omc1-s30.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Aug 2010 08:01:29 -0700
X-Originating-IP: [70.26.19.53]
X-Originating-Email: [tom111.taylor@bell.net]
Message-ID:
Received: from [192.168.2.11] ([70.26.19.53]) by BLU0-SMTP70.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Aug 2010 08:01:28 -0700
Date: Thu, 26 Aug 2010 11:01:25 -0400
From: Tom Taylor
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: pcn
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 26 Aug 2010 15:01:28.0672 (UTC) FILETIME=[8FB11E00:01CB452F]
Subject: [PCN] Definition of sustainable aggregate rate (SAR)
X-BeenThere: pcn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PCN WG list
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 26 Aug 2010 15:00:57 -0000
I'm adding the following definition to the CL and SM boundary node behaviour
drafts. Comments?
Sustainable aggregate rate (SAR)
The estimated maximum rate of PCN-traffic that can be admitted to
a given ingress-egress-aggregate at a given moment without causing
degradation of quality of service for the admitted flows. This value
is derived as part of the flow termination procedure, and is used
to determine how much PCN-traffic must be terminated to bring the
ingress-egress-aggregate back to its intended operating level.
For further details see .
Tom Taylor
From tom111.taylor@bell.net Thu Aug 26 08:53:40 2010
Return-Path:
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 36D9B3A6852 for ; Thu, 26 Aug 2010 08:53:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.001
X-Spam-Level:
X-Spam-Status: No, score=-99.001 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_50=0.001, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100]
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 PK3ha7Q831Ns for ; Thu, 26 Aug 2010 08:53:39 -0700 (PDT)
Received: from blu0-omc1-s32.blu0.hotmail.com (blu0-omc1-s32.blu0.hotmail.com [65.55.116.43]) by core3.amsl.com (Postfix) with ESMTP id E26E83A6843 for ; Thu, 26 Aug 2010 08:53:38 -0700 (PDT)
Received: from BLU0-SMTP10 ([65.55.116.7]) by blu0-omc1-s32.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Aug 2010 08:54:11 -0700
X-Originating-IP: [70.26.19.53]
X-Originating-Email: [tom111.taylor@bell.net]
Message-ID:
Received: from [192.168.2.11] ([70.26.19.53]) by BLU0-SMTP10.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Aug 2010 08:54:10 -0700
Date: Thu, 26 Aug 2010 11:54:07 -0400
From: Tom Taylor
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: pcn
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 26 Aug 2010 15:54:10.0898 (UTC) FILETIME=[EC868320:01CB4536]
Subject: [PCN] New technical point regarding loss of signalling
X-BeenThere: pcn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PCN WG list
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 26 Aug 2010 15:53:40 -0000
The current text regarding loss of signalling between the Decision Point and
PCN-egress-node reads as follows:
"If the Decision Point fails to receive reports from a given
PCN-egress-node for a configurable interval T-fail, it
SHOULD cease to admit flows to that aggregate
and raise an alarm to management."
This needs to be expanded a bit to consider the cases of centralized and
decentralized Decision Point separately. For the Decision Point collocated with
a PCN-ingress-node, there is just one ingress-egress-aggregate involved, as the
text implies. However, for a centralized Decision Point, the text should say
that no more flows are admitted to any ingress-egress-aggregate passing through
the PCN-egress-node concerned.
For thoroughness, signalling failure between the Decision Point and a
PCN-ingress-node should be covered, but the situation is rather peculiar. The
PCN-ingress-node is still forwarding flows, since otherwise flow termination
wouldn't be required. But it is not responding to signalling. I guess the only
action is logging and alarming, since the Decision Point can't do anything else
if signalling isn't working.
Tom Taylor
From menth@informatik.uni-wuerzburg.de Thu Aug 26 09:19:02 2010
Return-Path:
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 57D293A6988 for ; Thu, 26 Aug 2010 09:19:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.624
X-Spam-Level:
X-Spam-Status: No, score=-4.624 tagged_above=-999 required=5 tests=[AWL=-0.975, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
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 TtMXQlCjf0b7 for ; Thu, 26 Aug 2010 09:19:01 -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 108B03A69F2 for ; Thu, 26 Aug 2010 09:19:01 -0700 (PDT)
Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id B81895ACA8; Thu, 26 Aug 2010 18:19:32 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id B4D2D5AC9A; Thu, 26 Aug 2010 18:19:32 +0200 (CEST)
X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de
Received: from [192.168.1.2] (wrzb-4d004281.pool.mediaWays.net [77.0.66.129]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTPSA id 768A641E47; Thu, 26 Aug 2010 18:19:32 +0200 (CEST)
Message-ID: <4C7693E7.5080402@informatik.uni-wuerzburg.de>
Date: Thu, 26 Aug 2010 18:18:47 +0200
From: Michael Menth
Organization: University of Wuerzburg
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: Tom Taylor
References:
In-Reply-To:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: pcn
Subject: Re: [PCN] Definition of sustainable aggregate rate (SAR)
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
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 26 Aug 2010 16:19:02 -0000
Hi Tom,
what's possibly missing in this definition is the idea that the SAR is
the proportional share of the current rate of all IEAs carried over a
bottleneck link that does not cause pre-congestion.
Regards,
Michael
Am 26.08.2010 17:01, schrieb Tom Taylor:
> I'm adding the following definition to the CL and SM boundary node
> behaviour drafts. Comments?
>
> Sustainable aggregate rate (SAR)
>
> The estimated maximum rate of PCN-traffic that can be admitted to
> a given ingress-egress-aggregate at a given moment without causing
> degradation of quality of service for the admitted flows. This value
> is derived as part of the flow termination procedure, and is used
> to determine how much PCN-traffic must be terminated to bring the
> ingress-egress-aggregate back to its intended operating level.
> For further details see .
>
> Tom Taylor
> _______________________________________________
> PCN mailing list
> PCN@ietf.org
> https://www.ietf.org/mailman/listinfo/pcn
--
PD Dr. habil. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/31-86644 (new), fax: (+49)-931/31-86632 (new)
mailto:menth@informatik.uni-wuerzburg.de
http://www3.informatik.uni-wuerzburg.de/research/ngn
From menth@informatik.uni-wuerzburg.de Thu Aug 26 09:50:03 2010
Return-Path:
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 CFCA83A6A6B for ; Thu, 26 Aug 2010 09:50:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.729
X-Spam-Level:
X-Spam-Status: No, score=-5.729 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
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 kVeoF37jowAV for ; Thu, 26 Aug 2010 09:50:01 -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 0C9C63A6A12 for ; Thu, 26 Aug 2010 09:50:01 -0700 (PDT)
Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 3EAE85AC9B; Thu, 26 Aug 2010 18:50:33 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 3AD125AC84; Thu, 26 Aug 2010 18:50:33 +0200 (CEST)
X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de
Received: from [192.168.1.2] (wrzb-4d004281.pool.mediaWays.net [77.0.66.129]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTPSA id EDB795CDCB; Thu, 26 Aug 2010 18:50:32 +0200 (CEST)
Message-ID: <4C769B2B.7000009@informatik.uni-wuerzburg.de>
Date: Thu, 26 Aug 2010 18:49:47 +0200
From: Michael Menth
Organization: University of Wuerzburg
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: Tom Taylor
References:
In-Reply-To:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: pcn
Subject: Re: [PCN] New technical point regarding loss of signalling
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
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 26 Aug 2010 16:50:03 -0000
Hi Tom,
your question raises another question. Are the timer values related to
ingress-egress-aggregates or to egress-decision-point pairs? I assume
that it is the former. Therefore, I think no addition is necessary: if
communication between an egress node and the decision point
fundamentally fails, the timer for all IEAs expire.
Regards,
Michael
Am 26.08.2010 17:54, schrieb Tom Taylor:
> The current text regarding loss of signalling between the Decision
> Point and PCN-egress-node reads as follows:
>
> "If the Decision Point fails to receive reports from a given
> PCN-egress-node for a configurable interval T-fail, it
> SHOULD cease to admit flows to that aggregate
> and raise an alarm to management."
>
> This needs to be expanded a bit to consider the cases of centralized
> and decentralized Decision Point separately. For the Decision Point
> collocated with a PCN-ingress-node, there is just one
> ingress-egress-aggregate involved, as the text implies. However, for a
> centralized Decision Point, the text should say that no more flows are
> admitted to any ingress-egress-aggregate passing through the
> PCN-egress-node concerned.
>
> For thoroughness, signalling failure between the Decision Point and a
> PCN-ingress-node should be covered, but the situation is rather
> peculiar. The PCN-ingress-node is still forwarding flows, since
> otherwise flow termination wouldn't be required. But it is not
> responding to signalling. I guess the only action is logging and
> alarming, since the Decision Point can't do anything else if
> signalling isn't working.
>
> Tom Taylor
> _______________________________________________
> PCN mailing list
> PCN@ietf.org
> https://www.ietf.org/mailman/listinfo/pcn
--
PD Dr. habil. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/31-86644 (new), fax: (+49)-931/31-86632 (new)
mailto:menth@informatik.uni-wuerzburg.de
http://www3.informatik.uni-wuerzburg.de/research/ngn
From philip.eardley@bt.com Thu Aug 26 09:52:30 2010
Return-Path:
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 9DE153A6AB0 for ; Thu, 26 Aug 2010 09:52:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.577
X-Spam-Level:
X-Spam-Status: No, score=-101.577 tagged_above=-999 required=5 tests=[AWL=0.469, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100]
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 ty+aXN2ZEuSr for ; Thu, 26 Aug 2010 09:52:28 -0700 (PDT)
Received: from smtpe1.intersmtp.com (smtp63.intersmtp.COM [62.239.224.236]) by core3.amsl.com (Postfix) with ESMTP id C3B023A6AA2 for ; Thu, 26 Aug 2010 09:52:27 -0700 (PDT)
Received: from EVMHT63-UKRD.domain1.systemhost.net (10.36.3.100) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.1.436.0; Thu, 26 Aug 2010 17:53:02 +0100
Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.1.158]) by EVMHT63-UKRD.domain1.systemhost.net ([10.36.3.100]) with mapi; Thu, 26 Aug 2010 17:52:59 +0100
From:
To: ,
Date: Thu, 26 Aug 2010 17:52:59 +0100
Thread-Topic: [PCN] Definition of sustainable aggregate rate (SAR)
Thread-Index: ActFOpvjokgQ8y/8TXue5wQvuPiRygABBRnw
Message-ID: <4C22FF8FA5626046BF68899C06A0C9F711238CBDD9@EMV67-UKRD.domain1.systemhost.net>
In-Reply-To: <4C7693E7.5080402@informatik.uni-wuerzburg.de>
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-GB
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: pcn@ietf.org
Subject: Re: [PCN] Definition of sustainable aggregate rate (SAR)
X-BeenThere: pcn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PCN WG list
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 26 Aug 2010 16:52:30 -0000
I guess it should relate somehow to PCN-supportable-rate.
You could tweak your definition as the SAR becomes meaningful (only) when s=
ome traffic needs to be terminated - if there's only a little traffic, then=
there's no estimated maximum rate.
>From RFC5559:
o PCN-supportable-rate: the rate of PCN-traffic on a link down to
which PCN flow termination should, if necessary, terminate already
admitted PCN-flows.
> -----Original Message-----
> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On
> Behalf Of Michael Menth
> Sent: 26 August 2010 17:19
> To: Tom Taylor
> Cc: pcn
> Subject: Re: [PCN] Definition of sustainable aggregate rate (SAR)
>
>
>
> Hi Tom,
>
> what's possibly missing in this definition is the idea that
> the SAR is
> the proportional share of the current rate of all IEAs carried over a
> bottleneck link that does not cause pre-congestion.
>
> Regards,
>
> Michael
>
> Am 26.08.2010 17:01, schrieb Tom Taylor:
> > I'm adding the following definition to the CL and SM boundary node
> > behaviour drafts. Comments?
> >
> > Sustainable aggregate rate (SAR)
> >
> > The estimated maximum rate of PCN-traffic that can be admitted to a
> > given ingress-egress-aggregate at a given moment without causing
> > degradation of quality of service for the admitted flows.
> This value
> > is derived as part of the flow termination procedure, and
> is used to
> > determine how much PCN-traffic must be terminated to bring the
> > ingress-egress-aggregate back to its intended operating level. For
> > further details see .
> >
> > Tom Taylor
> > _______________________________________________
> > PCN mailing list
> > PCN@ietf.org
> > https://www.ietf.org/mailman/listinfo/pcn
>
> --
> PD Dr. habil. Michael Menth, Assistant Professor
> University of Wuerzburg, Institute of Computer Science
> Am Hubland, D-97074 Wuerzburg, Germany, room B206
> phone: (+49)-931/31-86644 (new), fax: (+49)-931/31-86632
> (new) mailto:menth@informatik.uni-wuerzburg.de
> http://www3.informatik.uni-wuerzburg.de/research/ngn
>
> _______________________________________________
> PCN mailing list
> PCN@ietf.org
> https://www.ietf.org/mailman/listinfo/pcn
>
From tom111.taylor@bell.net Thu Aug 26 09:59:20 2010
Return-Path:
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 0F1163A6A03 for ; Thu, 26 Aug 2010 09:59:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.009
X-Spam-Level:
X-Spam-Status: No, score=-100.009 tagged_above=-999 required=5 tests=[AWL=1.187, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100]
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 fFPtw99VVESN for ; Thu, 26 Aug 2010 09:59:18 -0700 (PDT)
Received: from blu0-omc1-s37.blu0.hotmail.com (blu0-omc1-s37.blu0.hotmail.com [65.55.116.48]) by core3.amsl.com (Postfix) with ESMTP id C2DC13A6896 for ; Thu, 26 Aug 2010 09:59:18 -0700 (PDT)
Received: from BLU0-SMTP22 ([65.55.116.8]) by blu0-omc1-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Aug 2010 09:59:51 -0700
X-Originating-IP: [70.26.19.53]
X-Originating-Email: [tom111.taylor@bell.net]
Message-ID:
Received: from [192.168.2.11] ([70.26.19.53]) by BLU0-SMTP22.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Aug 2010 09:59:50 -0700
Date: Thu, 26 Aug 2010 12:59:47 -0400
From: Tom Taylor
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: philip.eardley@bt.com
References: <4C22FF8FA5626046BF68899C06A0C9F711238CBDD9@EMV67-UKRD.domain1.systemhost.net>
In-Reply-To: <4C22FF8FA5626046BF68899C06A0C9F711238CBDD9@EMV67-UKRD.domain1.systemhost.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 26 Aug 2010 16:59:50.0778 (UTC) FILETIME=[18E07DA0:01CB4540]
Cc: pcn@ietf.org
Subject: Re: [PCN] Definition of sustainable aggregate rate (SAR)
X-BeenThere: pcn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PCN WG list
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 26 Aug 2010 16:59:20 -0000
Too bad that's defined for a link rather than a path. I suppose I could define
it as the minimum over all links carrying the aggregate.
On 26/08/2010 12:52 PM, philip.eardley@bt.com wrote:
> I guess it should relate somehow to PCN-supportable-rate.
>
> You could tweak your definition as the SAR becomes meaningful (only) when some traffic needs to be terminated - if there's only a little traffic, then there's no estimated maximum rate.
>
>> From RFC5559:
> o PCN-supportable-rate: the rate of PCN-traffic on a link down to
> which PCN flow termination should, if necessary, terminate already
> admitted PCN-flows.
>
>> -----Original Message-----
>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On
>> Behalf Of Michael Menth
>> Sent: 26 August 2010 17:19
>> To: Tom Taylor
>> Cc: pcn
>> Subject: Re: [PCN] Definition of sustainable aggregate rate (SAR)
>>
>>
>>
>> Hi Tom,
>>
>> what's possibly missing in this definition is the idea that
>> the SAR is
>> the proportional share of the current rate of all IEAs carried over a
>> bottleneck link that does not cause pre-congestion.
>>
>> Regards,
>>
>> Michael
>>
>> Am 26.08.2010 17:01, schrieb Tom Taylor:
>>> I'm adding the following definition to the CL and SM boundary node
>>> behaviour drafts. Comments?
>>>
>>> Sustainable aggregate rate (SAR)
>>>
>>> The estimated maximum rate of PCN-traffic that can be admitted to a
>>> given ingress-egress-aggregate at a given moment without causing
>>> degradation of quality of service for the admitted flows.
>> This value
>>> is derived as part of the flow termination procedure, and
>> is used to
>>> determine how much PCN-traffic must be terminated to bring the
>>> ingress-egress-aggregate back to its intended operating level. For
>>> further details see.
>>>
>>> Tom Taylor
>>> _______________________________________________
>>> PCN mailing list
>>> PCN@ietf.org
>>> https://www.ietf.org/mailman/listinfo/pcn
>>
>> --
>> PD Dr. habil. Michael Menth, Assistant Professor
>> University of Wuerzburg, Institute of Computer Science
>> Am Hubland, D-97074 Wuerzburg, Germany, room B206
>> phone: (+49)-931/31-86644 (new), fax: (+49)-931/31-86632
>> (new) mailto:menth@informatik.uni-wuerzburg.de
>> http://www3.informatik.uni-wuerzburg.de/research/ngn
>>
>> _______________________________________________
>> PCN mailing list
>> PCN@ietf.org
>> https://www.ietf.org/mailman/listinfo/pcn
>>
>
>
From menth@informatik.uni-wuerzburg.de Thu Aug 26 11:22:21 2010
Return-Path:
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 300853A686B for ; Thu, 26 Aug 2010 11:22:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.516
X-Spam-Level:
X-Spam-Status: No, score=-5.516 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4]
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 4tdTq+IeYZdU for ; Thu, 26 Aug 2010 11:22:19 -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 CC49A3A6826 for ; Thu, 26 Aug 2010 11:22:18 -0700 (PDT)
Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 253072195B; Thu, 26 Aug 2010 20:22:49 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 2159C49066; Thu, 26 Aug 2010 20:22:49 +0200 (CEST)
X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de
Received: from [192.168.1.2] (wrzb-4d004281.pool.mediaWays.net [77.0.66.129]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTPSA id BD7845CDD6; Thu, 26 Aug 2010 20:22:48 +0200 (CEST)
Message-ID: <4C76B0CB.4010908@informatik.uni-wuerzburg.de>
Date: Thu, 26 Aug 2010 20:22:03 +0200
From: Michael Menth
Organization: University of Wuerzburg
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: Tom Taylor
References: <4C22FF8FA5626046BF68899C06A0C9F711238CBDD9@EMV67-UKRD.domain1.systemhost.net>
In-Reply-To:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: pcn@ietf.org
Subject: Re: [PCN] Definition of sustainable aggregate rate (SAR)
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
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 26 Aug 2010 18:22:21 -0000
Hi Tom,
try this one:
Sustainable-aggregate-rate: estimated rate of an
ingress-egress-aggregate such that the PCN-rate on any link does no
longer exceed its PCN-supportable rate when all
ingress-egress-aggregates reduce their PCN-rates to their
sustainable-aggregate-rates.
It has a relation to PCN-supportable-rates (Phil's concern) and makes
clear that termination on multiple ingress-egress-aggregates is needed.
Regards,
Michael
Am 26.08.2010 18:59, schrieb Tom Taylor:
> Too bad that's defined for a link rather than a path. I suppose I
> could define it as the minimum over all links carrying the aggregate.
>
> On 26/08/2010 12:52 PM, philip.eardley@bt.com wrote:
>> I guess it should relate somehow to PCN-supportable-rate.
>>
>> You could tweak your definition as the SAR becomes meaningful (only)
>> when some traffic needs to be terminated - if there's only a little
>> traffic, then there's no estimated maximum rate.
>>
>>> From RFC5559:
>> o PCN-supportable-rate: the rate of PCN-traffic on a link down to
>> which PCN flow termination should, if necessary, terminate
>> already
>> admitted PCN-flows.
>>
>>> -----Original Message-----
>>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On
>>> Behalf Of Michael Menth
>>> Sent: 26 August 2010 17:19
>>> To: Tom Taylor
>>> Cc: pcn
>>> Subject: Re: [PCN] Definition of sustainable aggregate rate (SAR)
>>>
>>>
>>>
>>> Hi Tom,
>>>
>>> what's possibly missing in this definition is the idea that
>>> the SAR is
>>> the proportional share of the current rate of all IEAs carried over a
>>> bottleneck link that does not cause pre-congestion.
>>>
>>> Regards,
>>>
>>> Michael
>>>
>>> Am 26.08.2010 17:01, schrieb Tom Taylor:
>>>> I'm adding the following definition to the CL and SM boundary node
>>>> behaviour drafts. Comments?
>>>>
>>>> Sustainable aggregate rate (SAR)
>>>>
>>>> The estimated maximum rate of PCN-traffic that can be admitted to a
>>>> given ingress-egress-aggregate at a given moment without causing
>>>> degradation of quality of service for the admitted flows.
>>> This value
>>>> is derived as part of the flow termination procedure, and
>>> is used to
>>>> determine how much PCN-traffic must be terminated to bring the
>>>> ingress-egress-aggregate back to its intended operating level. For
>>>> further details see.
>>>>
>>>> Tom Taylor
>>>> _______________________________________________
>>>> PCN mailing list
>>>> PCN@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/pcn
>>>
>>> --
>>> PD Dr. habil. Michael Menth, Assistant Professor
>>> University of Wuerzburg, Institute of Computer Science
>>> Am Hubland, D-97074 Wuerzburg, Germany, room B206
>>> phone: (+49)-931/31-86644 (new), fax: (+49)-931/31-86632
>>> (new) mailto:menth@informatik.uni-wuerzburg.de
>>> http://www3.informatik.uni-wuerzburg.de/research/ngn
>>>
>>> _______________________________________________
>>> PCN mailing list
>>> PCN@ietf.org
>>> https://www.ietf.org/mailman/listinfo/pcn
>>>
>>
>>
--
PD Dr. habil. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/31-86644 (new), fax: (+49)-931/31-86632 (new)
mailto:menth@informatik.uni-wuerzburg.de
http://www3.informatik.uni-wuerzburg.de/research/ngn
From toby@moncaster.com Thu Aug 26 13:08:46 2010
Return-Path:
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 7B4473A6AD6 for ; Thu, 26 Aug 2010 13:08:46 -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_34=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 aECekJjJARah for ; Thu, 26 Aug 2010 13:08:45 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by core3.amsl.com (Postfix) with ESMTP id C2FBF3A6ACA for ; Thu, 26 Aug 2010 13:08:44 -0700 (PDT)
Received: from TobysHP (host86-143-222-243.range86-143.btcentralplus.com [86.143.222.243]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0MJF9e-1OqMea3zHG-003FkL; Thu, 26 Aug 2010 22:09:11 +0200
From: "Toby Moncaster"
To: , "'Tom Taylor'"
References: <4C22FF8FA5626046BF68899C06A0C9F711238CBDD9@EMV67-UKRD.domain1.systemhost.net> <4C76B0CB.4010908@informatik.uni-wuerzburg.de>
In-Reply-To: <4C76B0CB.4010908@informatik.uni-wuerzburg.de>
Date: Thu, 26 Aug 2010 21:09:07 +0100
Message-ID: <001d01cb455a$8a31be00$9e953a00$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: ActFS7TlheSoRTCORvmqXZs2Q8Y+sgADKBNg
Content-Language: en-gb
X-Provags-ID: V02:K0:HdBPbSb+LMu3uM/2jsHlokpjKFbLRYk3DA337pyIKAg YaTVjaZnKbxpmquacHNcoxg9C5dQqlthXjwR/Q/Ck0U8P6/fzn HBZH0ENz5QxEScAi6D0dldRYirdHdTNO1lVnUzHrBFG8VZsQ+4 fRMwpvOY+bXBDYCoVnRaHZIs+z/NvRgdiFjZ/499y0JpN3i8cT 6kN55DBA9XF6ELP5PsIFpFReLlqAVSG14kMeF0OUrw=
Cc: pcn@ietf.org
Subject: Re: [PCN] Definition of sustainable aggregate rate (SAR)
X-BeenThere: pcn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PCN WG list
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 26 Aug 2010 20:08:46 -0000
The trouble about Michael's version is it is a bit circular...
I don't know if it is any better, but how about:
"Sustainable-aggregate-rate: the estimated rate for a particular
ingress-egress-aggregate that ensures that the PCN-rate on any constituent
link does not exceed the PCN-supportable rate for that link. Note that any
other ingress-egress-aggregates sharing that same link will also be reducing
their rates towards their Sustainable-aggregate-rate."
This is a little stilted, but I think it is saying what we actually mean.
Toby
> -----Original Message-----
> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of
> Michael Menth
> Sent: 26 August 2010 19:22
> To: Tom Taylor
> Cc: pcn@ietf.org
> Subject: Re: [PCN] Definition of sustainable aggregate rate (SAR)
>
> Hi Tom,
>
> try this one:
>
> Sustainable-aggregate-rate: estimated rate of an
> ingress-egress-aggregate such that the PCN-rate on any link does no
> longer exceed its PCN-supportable rate when all
> ingress-egress-aggregates reduce their PCN-rates to their
> sustainable-aggregate-rates.
>
> It has a relation to PCN-supportable-rates (Phil's concern) and makes
> clear that termination on multiple ingress-egress-aggregates is needed.
>
> Regards,
>
> Michael
>
>
> Am 26.08.2010 18:59, schrieb Tom Taylor:
> > Too bad that's defined for a link rather than a path. I suppose I
> > could define it as the minimum over all links carrying the aggregate.
> >
> > On 26/08/2010 12:52 PM, philip.eardley@bt.com wrote:
> >> I guess it should relate somehow to PCN-supportable-rate.
> >>
> >> You could tweak your definition as the SAR becomes meaningful (only)
> >> when some traffic needs to be terminated - if there's only a little
> >> traffic, then there's no estimated maximum rate.
> >>
> >>> From RFC5559:
> >> o PCN-supportable-rate: the rate of PCN-traffic on a link down to
> >> which PCN flow termination should, if necessary, terminate
> >> already
> >> admitted PCN-flows.
> >>
> >>> -----Original Message-----
> >>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On
> >>> Behalf Of Michael Menth
> >>> Sent: 26 August 2010 17:19
> >>> To: Tom Taylor
> >>> Cc: pcn
> >>> Subject: Re: [PCN] Definition of sustainable aggregate rate (SAR)
> >>>
> >>>
> >>>
> >>> Hi Tom,
> >>>
> >>> what's possibly missing in this definition is the idea that
> >>> the SAR is
> >>> the proportional share of the current rate of all IEAs carried over
> a
> >>> bottleneck link that does not cause pre-congestion.
> >>>
> >>> Regards,
> >>>
> >>> Michael
> >>>
> >>> Am 26.08.2010 17:01, schrieb Tom Taylor:
> >>>> I'm adding the following definition to the CL and SM boundary node
> >>>> behaviour drafts. Comments?
> >>>>
> >>>> Sustainable aggregate rate (SAR)
> >>>>
> >>>> The estimated maximum rate of PCN-traffic that can be admitted to
> a
> >>>> given ingress-egress-aggregate at a given moment without causing
> >>>> degradation of quality of service for the admitted flows.
> >>> This value
> >>>> is derived as part of the flow termination procedure, and
> >>> is used to
> >>>> determine how much PCN-traffic must be terminated to bring the
> >>>> ingress-egress-aggregate back to its intended operating level. For
> >>>> further details see.
> >>>>
> >>>> Tom Taylor
> >>>> _______________________________________________
> >>>> PCN mailing list
> >>>> PCN@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/pcn
> >>>
> >>> --
> >>> PD Dr. habil. Michael Menth, Assistant Professor
> >>> University of Wuerzburg, Institute of Computer Science
> >>> Am Hubland, D-97074 Wuerzburg, Germany, room B206
> >>> phone: (+49)-931/31-86644 (new), fax: (+49)-931/31-86632
> >>> (new) mailto:menth@informatik.uni-wuerzburg.de
> >>> http://www3.informatik.uni-wuerzburg.de/research/ngn
> >>>
> >>> _______________________________________________
> >>> PCN mailing list
> >>> PCN@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/pcn
> >>>
> >>
> >>
>
> --
> PD Dr. habil. Michael Menth, Assistant Professor
> University of Wuerzburg, Institute of Computer Science
> Am Hubland, D-97074 Wuerzburg, Germany, room B206
> phone: (+49)-931/31-86644 (new), fax: (+49)-931/31-86632 (new)
> mailto:menth@informatik.uni-wuerzburg.de
> http://www3.informatik.uni-wuerzburg.de/research/ngn
>
> _______________________________________________
> PCN mailing list
> PCN@ietf.org
> https://www.ietf.org/mailman/listinfo/pcn
From daisuke.satoh@ntt-at.co.jp Thu Aug 26 17:50:28 2010
Return-Path:
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 4FF5B3A6B17 for ; Thu, 26 Aug 2010 17:50:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.86
X-Spam-Level:
X-Spam-Status: No, score=0.86 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_34=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 EKv8+lTv2Ea3 for ; Thu, 26 Aug 2010 17:50:25 -0700 (PDT)
Received: from sg.ntt-at.co.jp (roma.ntt-at.co.jp [202.253.160.19]) by core3.amsl.com (Postfix) with SMTP id 70D163A6B15 for ; Thu, 26 Aug 2010 17:50:25 -0700 (PDT)
Received: (qmail 87927 invoked by alias); 27 Aug 2010 09:50:57 +0900
Received: from gwall2.bb.ntt-at.co.jp (192.168.5.202) by subgate.bb.ntt-at.co.jp with SMTP; 27 Aug 2010 09:50:57 +0900
Received: (from root@localhost) by gwall2.bb.ntt-at.co.jp (8.13.1/8.13.1) id o7R0ovnh027959 for pcn@ietf.org; Fri, 27 Aug 2010 09:50:57 +0900
Received: from vcsrv1.bb.ntt-at.co.jp [192.168.2.9] by gwall2.bb.ntt-at.co.jp with ESMTP id KAA27958; Fri, 27 Aug 2010 09:50:57 +0900
Received: from vcsrv1.bb.ntt-at.co.jp (vcsrv1.bb.ntt-at.co.jp [127.0.0.1]) by vcsrv1.bb.ntt-at.co.jp (8.13.8/8.13.8) with ESMTP id o7R0ovlV007425 for ; Fri, 27 Aug 2010 09:50:57 +0900
Received: from pacific.bb.ntt-at.co.jp (pacific.bb.ntt-at.co.jp [192.168.2.16]) by vcsrv1.bb.ntt-at.co.jp (8.13.8/8.13.8) with ESMTP id o7R0ovno007422 for ; Fri, 27 Aug 2010 09:50:57 +0900
Received: from atmail21.am.ntt-at.co.jp (atmail21.am.ntt-at.co.jp [192.168.5.161]) by pacific.bb.ntt-at.co.jp (8.13.1/cf/pacific) with ESMTP id o7R0ouSO036231 for ; Fri, 27 Aug 2010 09:50:56 +0900 (JST) (envelope-from daisuke.satoh@ntt-at.co.jp)
Received: from [192.168.21.66] (ip21-066.tec.ntt-at.co.jp [192.168.21.66]) by atmail21.am.ntt-at.co.jp (Postfix) with ESMTP id ABCC356EA99; Fri, 27 Aug 2010 09:50:51 +0900 (JST)
Date: Fri, 27 Aug 2010 09:50:47 +0900
From: SATOH Daisuke
To: pcn@ietf.org
Message-Id: <20100827095047.2F8C.26AD349@ntt-at.co.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.51.06 [ja]
Subject: Re: [PCN] Definition of sustainable aggregate rate (SAR)
X-BeenThere: pcn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PCN WG list
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 27 Aug 2010 00:50:28 -0000
Hi Tom,
How about the following?
Sustainable aggregate rate (SAR)
The estimated maximum rate of PCN-traffic that can be admitted to a
given ingress-egress-aggregate at a given moment without causing degradation
of quality of service for the admitted flows. If the PCN-rate of any ingress-egress-aggregate
at the given moment is less than the estimated maximum rate of PCN-traffic,
PCN-rate on any link is less than PCN supportable rate. This estimated
maximum rate is derived as part of the flow termination procedure, and
is used to determine how much PCN-traffic must be terminated to bring
the ingress-egress-aggregate back to its intended operating level.
For further details see .
----
I only added one sentence to your original text:
If the PCN-rate of any ingress-egress-aggregate
at the given moment is less than the estimated maximum rate of PCN-traffic,
PCN-rate on any link is less than PCN-supportable-rate.
I believe that the first sentence of your original text is easy to
understand, even for those who are not familiar with PCN. My added
sentence meets Phil's concern. I guess Michael's definition is difficult
for those who are not familiar with PCN.
Best regards,
Daisuke
>
> Hi Tom,
>
> try this one:
>
> Sustainable-aggregate-rate: estimated rate of an
> ingress-egress-aggregate such that the PCN-rate on any link does no
> longer exceed its PCN-supportable rate when all
> ingress-egress-aggregates reduce their PCN-rates to their
> sustainable-aggregate-rates.
>
> It has a relation to PCN-supportable-rates (Phil's concern) and makes
> clear that termination on multiple ingress-egress-aggregates is needed.
>
> Regards,
>
> Michael
>
>
> Am 26.08.2010 18:59, schrieb Tom Taylor:
> > Too bad that's defined for a link rather than a path. I suppose I
> > could define it as the minimum over all links carrying the aggregate.
> >
> > On 26/08/2010 12:52 PM, philip.eardley@bt.com wrote:
> >> I guess it should relate somehow to PCN-supportable-rate.
> >>
> >> You could tweak your definition as the SAR becomes meaningful (only)
> >> when some traffic needs to be terminated - if there's only a little
> >> traffic, then there's no estimated maximum rate.
> >>
> >>> From RFC5559:
> >> o PCN-supportable-rate: the rate of PCN-traffic on a link down to
> >> which PCN flow termination should, if necessary, terminate
> >> already
> >> admitted PCN-flows.
> >>
> >>> -----Original Message-----
> >>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On
> >>> Behalf Of Michael Menth
> >>> Sent: 26 August 2010 17:19
> >>> To: Tom Taylor
> >>> Cc: pcn
> >>> Subject: Re: [PCN] Definition of sustainable aggregate rate (SAR)
> >>>
> >>>
> >>>
> >>> Hi Tom,
> >>>
> >>> what's possibly missing in this definition is the idea that
> >>> the SAR is
> >>> the proportional share of the current rate of all IEAs carried over a
> >>> bottleneck link that does not cause pre-congestion.
> >>>
> >>> Regards,
> >>>
> >>> Michael
> >>>
> >>> Am 26.08.2010 17:01, schrieb Tom Taylor:
> >>>> I'm adding the following definition to the CL and SM boundary node
> >>>> behaviour drafts. Comments?
> >>>>
> >>>> Sustainable aggregate rate (SAR)
> >>>>
> >>>> The estimated maximum rate of PCN-traffic that can be admitted to a
> >>>> given ingress-egress-aggregate at a given moment without causing
> >>>> degradation of quality of service for the admitted flows.
> >>> This value
> >>>> is derived as part of the flow termination procedure, and
> >>> is used to
> >>>> determine how much PCN-traffic must be terminated to bring the
> >>>> ingress-egress-aggregate back to its intended operating level. For
> >>>> further details see.
> >>>>
> >>>> Tom Taylor
> >>>> _______________________________________________
> >>>> PCN mailing list
> >>>> PCN@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/pcn
> >>>
> >>> --
> >>> PD Dr. habil. Michael Menth, Assistant Professor
> >>> University of Wuerzburg, Institute of Computer Science
> >>> Am Hubland, D-97074 Wuerzburg, Germany, room B206
> >>> phone: (+49)-931/31-86644 (new), fax: (+49)-931/31-86632
> >>> (new) mailto:menth@informatik.uni-wuerzburg.de
> >>> http://www3.informatik.uni-wuerzburg.de/research/ngn
> >>>
> >>> _______________________________________________
> >>> PCN mailing list
> >>> PCN@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/pcn
> >>>
> >>
> >>
From rbriscoe@jungle.bt.co.uk Fri Aug 27 00:34:28 2010
Return-Path:
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 441E63A6B7A for ; Fri, 27 Aug 2010 00:34:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.323
X-Spam-Level:
X-Spam-Status: No, score=-1.323 tagged_above=-999 required=5 tests=[AWL=0.794, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_LOW=-1]
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 tR0nWP3LaoZ2 for ; Fri, 27 Aug 2010 00:34:18 -0700 (PDT)
Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 994813A684B for ; Fri, 27 Aug 2010 00:33:56 -0700 (PDT)
Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Aug 2010 08:33:33 +0100
Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Aug 2010 08:33:33 +0100
Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1282894412200; Fri, 27 Aug 2010 08:33:32 +0100
Received: from MUT.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id o7R7XVSA004368 for ; Fri, 27 Aug 2010 08:33:31 +0100
Message-Id: <201008270733.o7R7XVSA004368@bagheera.jungle.bt.co.uk>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 27 Aug 2010 08:25:31 +0100
To: "PCN IETF list"
From: Bob Briscoe
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158
X-OriginalArrivalTime: 27 Aug 2010 07:33:33.0530 (UTC) FILETIME=[2745A3A0:01CB45BA]
Subject: [PCN] Fwd: IESG approved
X-BeenThere: pcn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PCN WG list
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 27 Aug 2010 07:34:28 -0000
PCN list,
This has bearing on decisions on PCN encoding.
The IESG approved ecn-tunnel unanimously yesterday at the first attempt.
It's just waiting for the approval announcement to be sent.
Then it's RFC Editor I believe.
Bob
>X-Virus-Scanned: amavisd-new at amsl.com
>To: ,
>
>X-Test-IDTracker: no
>Date: Thu, 26 Aug 2010 15:51:07 -0700
>From: IETF Secretariat
>X-SA-Exim-Connect-IP: 2001:1890:1112:1::20
>X-SA-Exim-Rcpt-To: draft-ietf-tsvwg-ecn-tunnel@tools.ietf.org,
>tsvwg-chairs@tools.ietf.org
>X-SA-Exim-Mail-From: ietf-secretariat-reply@ietf.org
>X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
> zinfandel.tools.ietf.org
>X-Spam-Level:
>X-Spam-Status: No, score=-4.1 required=3.0 tests=BAYES_00,SPF_PASS,
> X_IPV6_ADDRESS autolearn=ham version=3.3.1
>Subject: ID Tracker State Update Notice:
>X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000)
>X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org)
>X-OriginalArrivalTime: 26 Aug 2010 22:51:47.0307 (UTC)
>FILETIME=[434F1BB0:01CB4571]
>X-Spam-Score: 0 ()
>X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158
>X-MIME-Autoconverted: from quoted-printable to 8bit by
>bagheera.jungle.bt.co.uk id o7QMsoag002561
>X-EsetId: 0F8DF726E5FD95355CCF
>
>State changed to Approved-announcement to be sent from
>Approved-announcement to be sent::Point Raised - writeup needed by
>David Harrington
>ID Tracker URL: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-tunnel/
________________________________________________________________
Bob Briscoe, BT Innovate & Design
From slblake@petri-meat.com Sun Aug 29 20:24:41 2010
Return-Path:
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 9D5823A68E1 for ; Sun, 29 Aug 2010 20:24:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.039
X-Spam-Level:
X-Spam-Status: No, score=-101.039 tagged_above=-999 required=5 tests=[AWL=-1.040, BAYES_50=0.001, USER_IN_WHITELIST=-100]
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 0TOtEfSXcgYf for ; Sun, 29 Aug 2010 20:24:40 -0700 (PDT)
Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id C54E83A68FA for ; Sun, 29 Aug 2010 20:24:40 -0700 (PDT)
Received: from cpe-174-097-227-047.nc.res.rr.com ([174.97.227.47]) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1Opuzf-0000XJ-Fq for pcn@ietf.org; Sun, 29 Aug 2010 23:25:11 -0400
From: Steven Blake
To: pcn
In-Reply-To: <20100710133056.DE5561AFCCE@newdev.eecs.harvard.edu>
References: <20100710133056.DE5561AFCCE@newdev.eecs.harvard.edu>
Content-Type: text/plain; charset="UTF-8"
Date: Sun, 29 Aug 2010 23:25:09 -0400
Message-ID: <1283138709.2970.6.camel@tachyon>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12)
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - elom.tchmachines.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - petri-meat.com
Subject: Re: [PCN] PCN WGLC for the CL and SM edge behaviour drafts
X-BeenThere: pcn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PCN WG list
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 30 Aug 2010 03:24:42 -0000
On Sat, 2010-07-10 at 09:30 -0400, Scott O. Bradner wrote:
> this starts a WGLC for
> "PCN Boundary Node Behaviour for the Controlled Load (CL) Mode
> of Operation" (draft-ietf-pcn-cl-edge-behaviour) and
> "PCN Boundary Node Behaviour for the Single Marking (SM) Mode
> of Operation" (draft-ietf-pcn-sm-edge-behaviour).
>
> comments to the list by July 24 please
This last call has run a little longer than planned. :) But there have
been good stream of comments.
Let's wrap this WGLC up on Friday this week (Sept. 3).
Regards,
// Steve