RE: [PCN] 5.5. Probing functions

"Anna Charny (acharny)" <acharny@cisco.com> Mon, 05 November 2007 12:26 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 1Ip12V-0002OT-Jt; Mon, 05 Nov 2007 07:26:47 -0500
Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Ip12T-0002OG-R8 for pcn-confirm+ok@megatron.ietf.org; Mon, 05 Nov 2007 07:26:45 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip12T-0002O7-Fp for pcn@ietf.org; Mon, 05 Nov 2007 07:26:45 -0500
Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ip12S-0004aF-Qu for pcn@ietf.org; Mon, 05 Nov 2007 07:26:45 -0500
X-IronPort-AV: E=Sophos;i="4.21,372,1188802800"; d="scan'208";a="184919880"
Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 05 Nov 2007 04:26:42 -0800
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lA5CQdhm013648; Mon, 5 Nov 2007 04:26:39 -0800
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lA5CQVXn015853; Mon, 5 Nov 2007 12:26:34 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); Mon, 5 Nov 2007 07:26:31 -0500
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] 5.5. Probing functions
Date: Mon, 05 Nov 2007 07:26:30 -0500
Message-ID: <BABC859E6D0B9A4D8448CC7F41CD2B07056CA662@xmb-rtp-203.amer.cisco.com>
In-Reply-To: <98501B20-1260-4EE0-87F1-DCCA0770230D@nokia.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [PCN] 5.5. Probing functions
Thread-Index: AcgfiiiHCHCogjpWTb26i+sjfyw1+gAG5vug
From: "Anna Charny (acharny)" <acharny@cisco.com>
To: Lars Eggert <lars.eggert@nokia.com>, ext Georgios Karagiannis <karagian@cs.utwente.nl>
X-OriginalArrivalTime: 05 Nov 2007 12:26:31.0648 (UTC) FILETIME=[18D21600:01C81FA7]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15522.000
X-TM-AS-Result: No--15.366600-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=3895; t=1194265599; x=1195129599; c=relaxed/simple; s=sjdkim3002; 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]=205.5.=20Probing=20functions=20 |Sender:=20; bh=ruF3QdEVNN2Teq8dl2oH5fj5HeCsBAaBJeaeNk4R9bY=; b=Vo/CWMOu+avZxvm5GOPonjdJxMrDqNMMnUnTk/Ss7UkSXkCqcdSqX/qeHhfTKWWsQ9O6Xx71 3oKHHZaiASZJnPl8OQNYpCtsi/HydXXdh17ybR8eHEXEVM6oUPi6GLks;
Authentication-Results: sj-dkim-3; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632
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 below: 

> -----Original Message-----
> From: Lars Eggert [mailto:lars.eggert@nokia.com] 
> Sent: Monday, November 05, 2007 3:57 AM
> To: ext Georgios Karagiannis
> Cc: 'pcn'
> Subject: Re: [PCN] 5.5. Probing functions 
> 
> Hi,
> 
> On 2007-11-1, at 17:12, ext Georgios Karagiannis wrote:
> >> From: Lars Eggert [mailto:lars.eggert@nokia.com]
> >>
> >> 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.
> 
> ah - so this depends on the fact that a congested router uses 
> a marking scheme that always tags the packet with _something_.
> 
> In other words, this wouldn't work with Anna's single-bit 
> marking scheme, right? (Because that does not mark all 
> packets passing a congested router.)
> 

You are quite right - single marking would not necessarily mark a 
probe message - you would need to send several probes to notice 
that the path is congested with high enough probability - and that
introduces an additional delay.  This does not happen with schemes that
mark all packets with something when the  path is congested (for which
you need an additional codepoint).    

All of this assumes that RSVP message/probe goes through the same path
as the data - which happens for some ECMP hashes and not for others. 

Anna 


> > 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.
> 
> That adds delay, obviously. You also need to defined some 
> retransmission scheme that is safe without knowing the path RTT.
> 
> >>>> (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.
> 
> Thanks - I think I've understood this now. See above for my 
> comments about single-bit marking - this wouldn't work with 
> single-bit marking, would it?
> 
> >> This eliminates some of the marking options that have been 
> discussed.
> >
> > Georgios: No, please see above!
> 
> I still believe this does eliminate single-bit marking.
> 
> >>>> 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).
> 
> So what happens to the flow during the RTT needed for probing?  
> Packets are dropped? That would seem to significantly affect 
> various apps.
> 
> Lars
> 


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