RE: [PCN] 5.5. Probing functions

"Georgios Karagiannis" <karagian@cs.utwente.nl> Thu, 01 November 2007 12:40 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 1InZLh-0006m1-75; Thu, 01 Nov 2007 08:40:37 -0400
Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1InZLf-0006kk-Jc for pcn-confirm+ok@megatron.ietf.org; Thu, 01 Nov 2007 08:40:35 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InZLf-0006kU-5v for pcn@ietf.org; Thu, 01 Nov 2007 08:40:35 -0400
Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InZLY-0008FK-Nv for pcn@ietf.org; Thu, 01 Nov 2007 08:40:35 -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 lA1CdEun016742; Thu, 1 Nov 2007 13:40:24 +0100 (MET)
From: Georgios Karagiannis <karagian@cs.utwente.nl>
To: 'Lars Eggert' <lars.eggert@nokia.com>, 'pcn' <pcn@ietf.org>
References: <EB12498F-82EC-4630-9AED-392B23517ABC@nokia.com>
Subject: RE: [PCN] 5.5. Probing functions
Date: Thu, 01 Nov 2007 13:39:07 +0100
Message-ID: <000f01c81c84$5635b400$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: <EB12498F-82EC-4630-9AED-392B23517ABC@nokia.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Thread-Index: Acgce/ZeWG+LpeNgQzWdHjNX/OnIpQABxZNQ
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 13:40:25 +0100 (MET)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af
Cc:
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 receive some answers on the three questions!

> (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.

> 
> (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.


> 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.

Best regards,
Georgios


> -----Original Message-----
> From: Lars Eggert [mailto:lars.eggert@nokia.com] 
> Sent: donderdag 1 november 2007 12:38
> To: pcn
> Subject: [PCN] 5.5. Probing functions 
> 
> Hi,
> 
> I read through the section on probing in the architecture 
> draft, and have some comments. Folks know that I'm not too 
> thrilled with the idea of probing, so this should come as no 
> surprise...
> 
> > 5.5.  Probing functions
> >
> >    Probing functions are optional, and can be used for admission
> >    control.
> >
> >    PCN's admission control, as described so far, is essentially a
> >    reactive mechanism where the PCN-egress-node monitors the pre-
> >    congestion level for traffic from each PCN-ingress-node; if the 
> > level
> >    rises then it blocks new flows on that ingress-egress-aggregate.
> >    However, it's possible that an ingress-egress-aggregate 
> carries no
> >    traffic, and so the PCN-egress-node can't make an admission 
> > decision
> >    using the usual method described earlier.
> >
> >    One approach is to be "optimistic" and simply admit the new flow.
> >    However it's possible to envisage a scenario where the traffic 
> > levels
> >    on other ingress-egress-aggregates are already so high 
> that they're
> >    blocking new PCN-flows and admitting a new flow onto this 'empty'
> >    ingress-egress-aggregate would add extra traffic onto the link 
> > that's
> >    already pre-congested - which may 'tip the balance' so that PCN's
> >    flow termination mechanism is activated or some packets are 
> > dropped.
> >    This risk could be lessened by configuring on each link 
> sufficient
> >    'safety margin' above the PCN-lower-rate.
> >
> >    An alternative approach is to make PCN a more proactive 
> mechanism.
> >    The PCN-ingress-node explicitly determines, before admitting the
> >    prospective new flow, whether the ingress-egress-aggregate can
> >    support it.  This can be seen as a "pessimistic" approach, in
> >    contrast to the "optimism" of the approach above.  It involves
> >    probing: a PCN-ingress-node generates and sends probe packets in
> >    order to test the pre-congestion level that the flow would
> >    experience.
> 
> The above is a really good intro to the problem - nice job.
> 
> >    A probe packet is just a dummy data packet, generated by
> >    the PCN-ingress-node and addressed to the PCN-egress-node.  A
> >    downside of probing is that it adds delay to the 
> admission control
> >    process.  Also note that in the scenario described in 
> the previous
> >    paragraph (where traffic levels on other ingress-egress- 
> aggregates 
> > is
> >    already very high), the probe packets may also 'tip the balance'.
> 
> This discussion on the downsides of probing is too short. Let 
> me list some issues:
> 
> (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?
> 
> (2) How long do you need to probe for before you declare it 
> safe to admit the new flow? What's the delay before a new 
> flow can be admitted, and can apps actually deal with this delay?
> 
> (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?)
> 
> Without at least some good ideas about what the answers to 
> these questions will be I believe it is premature to declare 
> that probing is an optional component of PCN.
> 
> >    However, the risk should be reduced because it should be 
> possible 
> > to
> >    send probe packets for a shorter time and at a lower rate than a
> >    typical data flow.
> 
> This claim is related to (1) and (2) above. Is there any 
> evidence that is it possible to "send probe packets for a 
> shorter time and at a lower rate than a typical data flow"? 
> I'm not aware of any research in this space.
> 
> >    The situation is more complicated if there is multipath routing
> >    (ECMP) in the PCN-domain.  It is then possible for some 
> paths to be
> >    pre-congested whilst other paths within the same ingress-egress-
> >    aggregate aren't pre-congested.
> >
> >    One approach essentially ignores ECMP: as usual, admit 
> or block a 
> > new
> >    flow depending on the "measurements of PCN-traffic" on 
> the ingress-
> >    egress-aggregate.  This is rather similar to the "optimistic"
> >    approach above.
> >
> >    An alternative ("pessimistic" or "proactive") approach 
> is to probe
> >    the ECMP path.  The PCN-ingress-node generates and sends probe
> >    packets (dummy data) that follow the specific ECMP path that the 
> > new
> >    flow would do, in order to test the pre-congestion level 
> along it.
> >    An ECMP algorithm typically examines: the source and 
> destination IP
> >    addresses and port numbers, the protocol ID and the DSCP.  Hence
> >    these fields must have the same values in the probe 
> packets as the
> >    future data packets would have.  On the other hand, the 
> PCN-egress-
> >    node needs to consume the probe packets to ensure that they don't
> >    travel beyond the PCN-domain (eg they might confuse the 
> destination
> >    end node).  Hence somehow the PCN-egress-node has to be able to
> >    disambiguate a probe packet from a data packet, via the
> >    characteristic setting of particular bit(s) in the 
> packet's header 
> > or
> >    body - but these bit(s) mustn't be used by any 
> PCN-interior-node's
> >    ECMP algorithm.  This should be possible with a typical ECMP
> >    algorithm, but isn't in the general case.
> 
> Some things in this paragraph aren't specific to ECMP, such 
> as that the egress needs to consume the probe packets.
> 
> >    The probing functions are:
> >
> >    o  Make decision that probing is needed.  As described 
> above, this 
> > is
> >       when the ingress-egress-aggregate or the ECMP path carries no
> > PCN-
> >       traffic.  An alternative is always to probe, ie probe before
> >       admitting every PCN-flow.
> >
> >    o  (if required) Communicate the request that probing is needed
> > - the
> >       PCN-egress-node signals to the PCN-ingress-node that 
> probing is
> >       needed
> >
> >    o  Generate probe traffic - the PCN-ingress-node generates the 
> > probe
> >       traffic.  The appropriate number (or rate) of probe 
> packets will
> >       depend on the PCN-marking algorithm; for example an 
> excess-rate-
> >       marking algorithm generates fewer PCN-marks than a threshold-
> >       marking algorithm, and so will need more probe packets.
> >
> >    o  Forward probe packets - as far as PCN-interior-nodes are
> >       concerned, probe packets must be handled the same as (ordinary
> >       data) PCN-packets, in terms of routing, scheduling and PCN-
> >       marking.
> >
> >    o  Consume probe packets - the PCN-egress-node consumes probe 
> > packets
> >       to ensure that they don't travel beyond the PCN-domain.
> 
> Nice summary of the required functions.
> 
> Lars
> 




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