RE: [PCN] 5.5. Probing functions

"Georgios Karagiannis" <karagian@cs.utwente.nl> Thu, 01 November 2007 15:13 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 1Inbjj-0000DP-1U; Thu, 01 Nov 2007 11:13:35 -0400
Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Inbji-0000DK-En for pcn-confirm+ok@megatron.ietf.org; Thu, 01 Nov 2007 11:13:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Inbji-0000Cq-4R for pcn@ietf.org; Thu, 01 Nov 2007 11:13:34 -0400
Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Inbjg-00053g-QI for pcn@ietf.org; Thu, 01 Nov 2007 11:13:34 -0400
Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id lA1FCwZY015936; Thu, 1 Nov 2007 16:13:29 +0100 (MET)
From: Georgios Karagiannis <karagian@cs.utwente.nl>
To: 'Lars Eggert' <lars.eggert@nokia.com>
References: <EB12498F-82EC-4630-9AED-392B23517ABC@nokia.com> <000f01c81c84$5635b400$4c0d5982@dynamic.ewi.utwente.nl> <2723F111-5919-49CB-AC22-4A5A795F4852@nokia.com>
Subject: RE: [PCN] 5.5. Probing functions
Date: Thu, 01 Nov 2007 16:12:51 +0100
Message-ID: <001a01c81c99$b4735350$4c0d5982@dynamic.ewi.utwente.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <2723F111-5919-49CB-AC22-4A5A795F4852@nokia.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Thread-Index: AcgcjOMH1cGJAyzwS+6qIkWWHgBz2QACPUtQ
X-Spam-Score: 0 ()
X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Thu, 01 Nov 2007 16:13:30 +0100 (MET)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d
Cc: 'pcn' <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 Lars

Please see in line!

Best regards,
Georgios
 

> -----Original Message-----
> From: Lars Eggert [mailto:lars.eggert@nokia.com] 
> Sent: donderdag 1 november 2007 14:10
> To: ext Georgios Karagiannis
> Cc: 'pcn'
> Subject: Re: [PCN] 5.5. Probing functions 
> 
> Hi,
> 
> On 2007-11-1, at 14:39, ext Georgios Karagiannis wrote:
> >> (1) The ingress needs to generate traffic in a pattern and 
> at a rate 
> >> that lets it draw conclusions about whether it is OK to admit the 
> >> flow that is waiting for admission. How does it know what 
> >> characteristics the probe traffic should have and how does it 
> >> generate the probe traffic?
> >
> > Georgios: The PCN_ingress_node generates one probe packet 
> for each new 
> > incoming flow that requests access from the PCN_domain.
> 
> how is a single packet probing the path? It's not obvious to 
> me how one would derive bottleneck load based on a single 
> packet, i.e., based on one or zero markings.

Georgios: The PCN_ingress_node sends a probe packet and it waits 
for a response from the PCN_egress_node. 
If a PCN_interior_node is congested (is in admission control state),
then the probe will be marked, either using the PCN_marking or an additional
encoding, say PCN_Affected_marking.
If the probe packet is dropped on the way, then the PCN_ingress_node has to
know this
such that the probe packet is retransmitted. This can be done by using
retransmission timers at the PCN_ingress_node.

> 
> >> (2) How long do you need to probe for before you declare 
> it safe to 
> >> admit the new flow?
> > Georgios: One probe packet per new incoming and flow is 
> enough if the 
> > PCN_domain takes care that the probe packet will be marked 
> PCN_marked 
> > or using an other type of encoding, if it is passing through a 
> > congested PCN_interior_node.
> 
> Ah - so this requires the marking scheme to mark all packets 
> once the defined pre-congestion load level is reached, 
> instead of marking proportionally with an increase in load, 
> correct? 

Georgios: No! Marking proportionally is still needed, since it is also
needed
to encode the flow termination state of the PCN_interior nodes.
However, all packets that are passing through the congested node and are not
PCN_marked 
they will have to be remarked with this additional encoding, denoted as
PCN_Affected_marking.

> This eliminates some of the marking options that 
> have been discussed.

Georgios: No, please see above!



> 
> And you need to ensure that - after having gotten an 
> indication of "not loaded" from the path - the single flow 
> you're about to admit cannot by itself push the bottleneck 
> straight into overload. This is, because the "not loaded" 
> piece of information doesn't tell you how close to 
> pre-congestion the bottleneck is, and if it can actually 
> sustain the rate that the flow is going to send at.

Georgios: Yes, you are right, this is an issue that occurs in a similar way
on
all MBAC mechanisms. 

> 
> You could do this through appropriate configuration, i.e., 
> ensuring that the level at which you start marking is 
> sufficiently below the overload state that you can sustain 
> one new flow. Or two. Or three.  
> How much is enough?
> 
> And if you did this through configuration, i.e., making sure 
> that 1,2,3,... flows can be admitted, what's the benefit of 
> probing? Why not simply admit the flow?

Georgios: This preconfiguration might not be easy, but it is 
needed when any type of precongesion mechanism (that is not using probing) 
is used. 

When probing is used, then the PCN_egress_node is certain that when a
received probe is marked
that this probe (and thus all that packets that are associated with the flow
that generated the proobe packet) 
is/will be passing through the congested node. In this situation the
requesting 
flow is rejected. If the probe is not marked then 
the requesting flow is admitted. 
If probing is not used, then the PCN_egress_node cannot be certain about
such decissions.

Furthermore, when probing is used, the admission control mechanism also
works when the 
ingress/egress aggregate is not yet available/created at the
PCN_egress_node.
This cannot be done if probing is not used.

> 
> >> What's the delay before a new
> >> flow can be admitted, and can apps actually deal with this delay?
> >
> > The delay = one RTT (within PCN_domain).
> >
> >> (3) Since you're sending probe traffic at a rate that is 
> likely not 
> >> insignificant, how do you prevent the probe traffic itself from 
> >> causing congestion and triggering stop-admission or 
> flow-termination 
> >> actions? If you're treating it differently (e.g., at a lower 
> >> priority), how is what the probe traffic experiences still 
> >> representative of what the real flow would experience? 
> (How can you 
> >> treat it differently and still make ECMP work?)
> >
> > Georgios: By just sending one probe packet per new incoming 
> flow that 
> > requests access into the PCN_domain.
> 
> Lars
> 




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