RE: [PCN] Architecture draft - probing section & general updates.

"Anna Charny (acharny)" <acharny@cisco.com> Tue, 23 October 2007 13:38 UTC

Return-path: <pcn-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkJxh-0001LQ-EE; Tue, 23 Oct 2007 09:38:25 -0400
Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IkJxf-0001Ig-QB for pcn-confirm+ok@megatron.ietf.org; Tue, 23 Oct 2007 09:38:24 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkJxe-0001I9-Vi for pcn@ietf.org; Tue, 23 Oct 2007 09:38:22 -0400
Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkJxd-0000M0-Qc for pcn@ietf.org; Tue, 23 Oct 2007 09:38:22 -0400
X-IronPort-AV: E=Sophos;i="4.21,317,1188792000"; d="scan'208";a="135453512"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 23 Oct 2007 09:38:21 -0400
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9NDcLcW013644; Tue, 23 Oct 2007 09:38:21 -0400
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l9NDc8kF027714; Tue, 23 Oct 2007 13:38:21 GMT
Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Oct 2007 09:38:16 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [PCN] Architecture draft - probing section & general updates.
Date: Tue, 23 Oct 2007 09:38:15 -0400
Message-ID: <BABC859E6D0B9A4D8448CC7F41CD2B070558B12C@xmb-rtp-203.amer.cisco.com>
In-Reply-To: <1B6169C658325341A3B8066E23919E1C0DE8FE@S4DE8PSAANK.mitte.t-com.de>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [PCN] Architecture draft - probing section & general updates.
Thread-Index: AcgSW1AlagmbQOCGTY+NFlaP1Yyp9wAANMQgALxKnwAACpgUoA==
From: "Anna Charny (acharny)" <acharny@cisco.com>
To: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
X-OriginalArrivalTime: 23 Oct 2007 13:38:16.0404 (UTC) FILETIME=[F748F940:01C81579]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15500.002
X-TM-AS-Result: No--1.997800-8.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1736; t=1193146701; x=1194010701; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=20=22Anna=20Charny=20(acharny)=22=20<acharny@cisco.com> |Subject:=20RE=3A=20[PCN]=20Architecture=20draft=20-=20probing=20section= 20&=20general=20updates. |Sender:=20 |To:=20=22Geib,=20Ruediger=22=20<Ruediger.Geib@t-systems.com>; bh=nDAzEp2CHPmEGxltnAOwnhvfKAMfOOYdHcTEykOnsUQ=; b=jbP5Jg4MAoyGgSVxKpInc05UeZxGuvngiONl45d1c83yJCsjjJgUtvOgQn2Epb3YmldSFI+C bdjwSfulAfFZMzf69UlndqZoLW1wdQ7NQb+/PMPr2qCeQc5nMgsBXxKK;
Authentication-Results: rtp-dkim-1; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; );
X-Spam-Score: -4.0 (----)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
Cc: pcn@ietf.org
X-BeenThere: pcn@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: PCN WG list <pcn.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pcn>, <mailto:pcn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pcn>
List-Post: <mailto:pcn@ietf.org>
List-Help: <mailto:pcn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pcn>, <mailto:pcn-request@ietf.org?subject=subscribe>
Errors-To: pcn-bounces@ietf.org

Hi Ruediger,

I meant roughly the following. Suppose many ingress-egress aggregates
have on the average 1 flow.  If you have just one flow per
ingress-egress aggregate, when this flow arrives and is the only one
active in its ingress-egress pair, and if no 
probing of any kind is used, then effectively there is no admission
control for this aggregate.  If many such aggregates share a bottleneck,
then effectively all these ingress-egress aggregates have to be admitted
regardless of the state of the bottleneck.  In the extreme, if all
ingress-egress aggregates sharing a bottleneck consist of one flow, then
this bottleneck effectively does not have any admission control.  In
such situations probing might be quite useful, as it will enable
admission control. 

Of course one does not have to require that *all* ingress-egress
aggregates sharing a bottleneck have just one flow to have a similar
problem - just enough of them on the average to take a substantial share
of the bottleneck bandwidth.

Does it make sense?
Anna 

> -----Original Message-----
> From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] 
> Sent: Tuesday, October 23, 2007 4:26 AM
> To: Anna Charny (acharny)
> Cc: pcn@ietf.org
> Subject: RE: [PCN] Architecture draft - probing section & 
> general updates.
> 
> Anna,
> 
> could you re-write your point? I don't get the sense completely.
> 
> Thanks,
> 
> Rudiger
> 
> 
> |   - should the WG consider the case when expected number of 
> flows on 
> |very large number of ingress-egress aggregates sharing a 
> bottleneck has 
> |on the order of *one* flow.  Note that this is the case when probing 
> |might be needed.
> 


_______________________________________________
PCN mailing list
PCN@ietf.org
https://www1.ietf.org/mailman/listinfo/pcn