Re: [PCN] Re: 5.5. Probing functions

Michael Menth <menth@informatik.uni-wuerzburg.de> Tue, 06 November 2007 10:33 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 1IpLkZ-0007It-1h; Tue, 06 Nov 2007 05:33:39 -0500
Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IpLkW-0007Ge-UB for pcn-confirm+ok@megatron.ietf.org; Tue, 06 Nov 2007 05:33:36 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpLkW-0007G2-KF for pcn@ietf.org; Tue, 06 Nov 2007 05:33:36 -0500
Received: from wrzx28.rz.uni-wuerzburg.de ([132.187.3.28] helo=mailrelay.rz.uni-wuerzburg.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpLkT-0006Y5-IN for pcn@ietf.org; Tue, 06 Nov 2007 05:33:36 -0500
Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 0DE32D5E6; Tue, 6 Nov 2007 11:33:33 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 007B1DB0F; Tue, 6 Nov 2007 11:33:33 +0100 (CET)
Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id B06CCD5E6; Tue, 6 Nov 2007 11:33:30 +0100 (CET)
Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id lA6AXUh11396; Tue, 6 Nov 2007 11:33:30 +0100
Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 670FF6F591; Tue, 6 Nov 2007 11:26:02 +0100 (CET)
Message-ID: <4730411D.9010604@informatik.uni-wuerzburg.de>
Date: Tue, 06 Nov 2007 11:25:33 +0100
From: Michael Menth <menth@informatik.uni-wuerzburg.de>
Organization: University of Wuerzburg
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: philip.eardley@bt.com
Subject: Re: [PCN] Re: 5.5. Probing functions
References: <75A199C5D243C741BF3D3F1EBCEF9BA503B342E0@E03MVZ1-UKDY.domain1.systemhost.net>
In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B342E0@E03MVZ1-UKDY.domain1.systemhost.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53
Cc: pcn@ietf.org
X-BeenThere: pcn@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: menth@informatik.uni-wuerzburg.de
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 Phil and others,

I don't know how likely this is in operational networks, it certainly 
depends on topology, routing, and traffic dynamics.

We did a study on load balancing algorithms with a different focus. It 
turned out that with static load balancing significant imbalances occur 
due to statistical effects even if a 50:50 balance is envisaged.
http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/Menth06p.pdf

This is just one source of traffic imbalance. Another and more important 
issue is that links of a network can have substantially different 
utilization, no matter due to with reason (different bandwidth, 
different traffic load, different amount of backup capacity, ...). 
Therefore, some alternative paths of a single ingress-egress-aggregate 
have high utilization, others have low utilization. If the load 
increases, some flows of that aggregate must be blocked while others can 
safely be admitted.

If we do not consider this issue, we need to ask ourselves why we look 
at admission control at all for such networks instead of just doing 
reasonable overprovisioning (if it's possible and economically viable).

Regards,

    Michael


philip.eardley@bt.com wrote:
> Michael
>
> Do you have an idea of how likely this is? will it be the case that for
> a small increase in load all/most of the ECMP paths become full? Does it
> depend strongly on topology? If each link is shared by mnay ecmp paths
> from many different ingress-egress-aggregates is this less of a risk?
>
> phil
>
>   
>> -----Original Message-----
>> From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de]
>> Sent: 06 November 2007 08:29
>> To: Lars Eggert
>> Cc: Eardley,PL,Philip,CXR9 R; pcn@ietf.org
>> Subject: Re: [PCN] Re: 5.5. Probing functions
>>
>> Hi Lars and Phil,
>>
>> I think that one major motivation for probing is to make PCN capable
>>     
> to
>   
>> deal with multipath routing like ECMP. Some path are empty, others are
>> full. Some flows must be rejected, others can proceed although they
>>     
> all
>   
>> belong to the same ingress-egress-aggregate.
>>
>> Regards,
>>
>>     Michael
>>
>> Lars Eggert wrote:
>>     
>>> Hi,
>>>
>>> On 2007-11-5, at 21:30, ext philip.eardley@bt.com wrote:
>>>       
>>>> My impression is that probing advocates have 2 reasons:
>>>>         
>>> thanks for summarizing this! I think this does capture the main
>>>       
> points
>   
>>> made.
>>>
>>>       
>>>> - the on-going ingress-egress-aggregate measurement of marked pkts
>>>> doesn't work. Because there's often no traffic on this
>>>> ingress-egress-aggregate, or no traffic on the ECMP path; AND
>>>>         
> simply
>   
>>>> admitting the flow has a significant risk of leading to overload
>>>>         
> [pkts
>   
>>>> dropped &/or flows terminated]
>>>> - there's no signalling state on the PCN-boundary-nodes for this
>>>> ingress-egress-aggregate (and no traffic already on it); AND the
>>>>         
> router
>   
>>>> behaviour is such that every pkt is marked if the flow should be
>>>> blocked; AND just admitting the call is dangerous because there's a
>>>>         
>> good
>>     
>>>> chance of overload in some parts of the nw (near the edge where the
>>>> capacity is low). Hence probing creates no extra delay (since you
>>>>         
> have
>   
>>>> to send a signalling set-up msg anyway). Often this scenario is
>>>>         
> people
>   
>>>> who envisage PCN going to end terminals or at least further out
>>>>         
> than
>   
>>>> core nw [I think].
>>>>         
>>> Although I agree that we can construct scenarios where "simply
>>> admitting the flow has a significant risk of leading to overload", I
>>> still remain unclear on how likely such cases are in whatever we
>>> envision the most likely deployment scenarios to be. Basically, I
>>> worry that we're making the architecture complex for what will
>>>       
> provide
>   
>>> little real benefit in the end.
>>>
>>> Also, don't forget that using probing will mean dropping the packets
>>> of the flow waiting for admission for an RTT *every time* probing is
>>> used. Whereas "just admitting" may only cause overload sometimes.
>>> There is a tradeoff here - I believe it's possible to construct a
>>>       
> case
>   
>>> where probing hurts more than "just admitting."
>>>
>>> And I'm still waiting for someone to convince me that dropping the
>>> initial packets of a flow at the ingress during the probing RTT will
>>> result in something that is acceptable for apps.
>>>
>>>       
>>>> The first scenario will only happen in narrow conditions [flash
>>>>         
> crowds,
>   
>>>> many ingress-egress-aggregates without any traffic]. An alternative
>>>>         
> way
>   
>>>> of handling this is to limit the rate at which admit new flows [at
>>>>         
>> least
>>     
>>>> this makes the conditions when the problem occurs even narrower].
>>>>         
>>> And we should try to determine how narrow these conditions are. If
>>> they're very narrow, we may be able to avoid them through
>>> configuration suggestions (sufficient overprovisioning, sufficiently
>>> broad marking regions, etc.)
>>>
>>>       
>>>>  The second scenario seems to break the (link) aggregation
>>>>         
> assumption?
>   
>>>> presumably it could be solved by running different mechanism at the
>>>>         
>> edge
>>     
>>>> compared with at the core. [joe, sorry if you've already explained,
>>>>         
> the
>   
>>>> late hour => even poorer memory than usual.]
>>>>         
>>> Yes, we seem to be running into the "the number of flows across any
>>> potential aggregation bottleneck is sufficiently large for
>>>       
> stateless,
>   
>>> statistical mechanisms to be effective" restriction from the charter
>>> here. These scenarios seems to require a deterministic mechanism,
>>> while PCN is supposed to provide a probabilistic one.
>>>
>>> Lars
>>>
>>>       
> ------------------------------------------------------------------------
>   
>>> _______________________________________________
>>> PCN mailing list
>>> PCN@ietf.org
>>> https://www1.ietf.org/mailman/listinfo/pcn
>>>
>>>       
>> --
>> Dr. Michael Menth, Assistant Professor
>> University of Wuerzburg, Institute of Computer Science
>> Am Hubland, D-97074 Wuerzburg, Germany, room B206
>> phone: (+49)-931/888-6644, fax: (+49)-931/888-6632
>> mailto:menth@informatik.uni-wuerzburg.de
>> http://www3.informatik.uni-wuerzburg.de/research/ngn
>>     

-- 
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/888-6644, fax: (+49)-931/888-6632
mailto:menth@informatik.uni-wuerzburg.de
http://www3.informatik.uni-wuerzburg.de/research/ngn



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