Re: [tram] A few comments on draft-ietf-tram-stun-pmtud-17.txt

Gonzalo Camarillo <gonzalo.camarillo@ericsson.com> Tue, 09 February 2021 13:34 UTC

Return-Path: <gonzalo.camarillo@ericsson.com>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63D3B3A0A65 for <tram@ietfa.amsl.com>; Tue, 9 Feb 2021 05:34:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.351
X-Spam-Level:
X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.25, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLypUN3rBJ6H for <tram@ietfa.amsl.com>; Tue, 9 Feb 2021 05:34:36 -0800 (PST)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70084.outbound.protection.outlook.com [40.107.7.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1507D3A0A38 for <tram@ietf.org>; Tue, 9 Feb 2021 05:34:32 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Yyc/slKRb0uHADju0B2IvfH9NGu13v40NU/bxQdPTQ9D3coThFb7XWJ1YIws7KztfYQY6f9w5jnRIX/cLDZG00fwqGtuK0lFkP6foyNa162ZLAxRfoTJSTsLXN3op5CIcsqRrmwCRvVZ16mLcB9lZb+sYUnwiQWpFW9sWenPJ8rWv3hSvpKN8gFL3bFvwgewaQkm/jffGWl2PVvaLTleiGpmIcTrgtQwk3VfdNt3X/vDwxJL2T4xqC/nUVzkfM0OO15EXiVWw+oqPXd+NdMoDa4Xh/tbLwjYb64MczJ2D86IgLXNKcrPxuU/ugucr0FNM5VZ5Xdxzt3eK3IApQFWhg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pUlYpBKBaVsq4OftIwrxu3byEOUkcUP6ncMqv2XWLzM=; b=B/t5daAcvOxt9hBW7zIMAylR5sUqmddHosL17r9h57YSyccJ8L4czrsWFerz6uAGjbujPNis7HTYQfweMfioJDVw7HKP/fD0GbtdYJ6JmzVYiHk1BM6sM6rt/xAIfBr3T+g/l+54JNvexjxEzjBIUeuMRgPdEtMW+qm3i05ILMSHPRX2qaRwKrkbD/jivxeKa95O5xB/eSXFJa95CP8aajJEdhc+/zUVvkLTuYzvBC0+ok0RQKpSiR8RIQvj8zoTHaTW8Yp5i89YvZXSBzL50h9M6XAXxi7azQ27auWpcvLv7Rw9oXBeJKm4GRgmxgti8vlXqEy9FmKE0rXTL14M6w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pUlYpBKBaVsq4OftIwrxu3byEOUkcUP6ncMqv2XWLzM=; b=saPM4GfvxqJ0BHvAuNxdgJdS3St8GN7PyP9mFxFXCFJhuGtv11IUy/VEiFXNrbenxjpGMem/SrgywJ99oYUmwUbxe+fix3u4MZQQmD+ZcRAzakExC9RkNGetsTNupSgFJdyo06U4x0rM7Azh16qNe47Ri7bYjro0p1KbZ8Xe+BM=
Received: from (2603:10a6:7:8b::32) by HE1PR0701MB2841.eurprd07.prod.outlook.com (2603:10a6:3:4e::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3846.10; Tue, 9 Feb 2021 13:34:30 +0000
Received: from HE1PR0702MB3561.eurprd07.prod.outlook.com ([fe80::fd44:77e6:56b1:4511]) by HE1PR0702MB3561.eurprd07.prod.outlook.com ([fe80::fd44:77e6:56b1:4511%7]) with mapi id 15.20.3825.016; Tue, 9 Feb 2021 13:34:30 +0000
From: Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>
To: "Felipe Garrido (fegarrid)" <fegarrid@cisco.com>, Magnus Westerlund <magnus.westerlund@ericsson.com>, "gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>, "tram@ietf.org" <tram@ietf.org>
CC: "gorry@abdn.ac.uk" <gorry@abdn.ac.uk>, "Gonzalo Salgueiro (gsalguei)" <gsalguei@cisco.com>, Marc Petit-Huguenin <marc@petit-huguenin.org>
Thread-Topic: [tram] A few comments on draft-ietf-tram-stun-pmtud-17.txt
Thread-Index: AQHWrUQa6F7qt+ThhlNJe3AamA7G+apQdgxA
Date: Tue, 9 Feb 2021 13:34:30 +0000
Message-ID: <HE1PR0702MB3561321ADCF71A44D09C89E9838E9@HE1PR0702MB3561.eurprd07.prod.outlook.com>
References: <7c201e29-1a63-39ed-cdd9-3b8b9ac383e6@erg.abdn.ac.uk> <860e8240-ce51-5407-4187-92478262f87c@erg.abdn.ac.uk> <179FB260-1FAC-419B-B5F4-86F850177C97@cisco.com> <04b71d3e-1c79-cdc1-5b20-906732ffa768@erg.abdn.ac.uk> <025EEF1A-A751-4A45-A36F-70CCC043255C@cisco.com> <41CA9214-D8C3-4A40-BAB7-43BD40F40A63@cisco.com> <5c416da8-931c-cc51-8662-0841d3f87e31@erg.abdn.ac.uk> <e2c76060e674a703611358b2d626526146191b58.camel@ericsson.com> <AM5PR0701MB29965F604C5A74008467E975831D0@AM5PR0701MB2996.eurprd07.prod.outlook.com> <9933F21E-8D11-4924-85E8-7687C270426F@cisco.com>
In-Reply-To: <9933F21E-8D11-4924-85E8-7687C270426F@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [176.93.45.101]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 5a3b5492-8a4d-4de9-eaa7-08d8ccff6dc1
x-ms-traffictypediagnostic: HE1PR0701MB2841:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <HE1PR0701MB2841A05A237A2BF9F743C005838E9@HE1PR0701MB2841.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: d2TlpXjpG7hfXq3tml9OjJSW0Ha2QpG2fbe040JUwXZeSMkogQ+yRvbGYCn+ev3P37TlcjN7OIl3AJeBLNUpAAl5+msNl212eIoJvBju9SWjAMmk525MZEF++KWEdIgMRJesshbk+iUUhH5r7M2LFvT91Bj9zpOBvvV61NieUlcy5rOJ9fZ6Vpr1I1jzzm9OFp7pKslNCk2+tVBiyDDwHUf0+M91Yn/WE2K81Fc0wm/A65f/cml24Ju/G6OVXH1jmOdlJ5VXgwSWs9LrtYYpwiYfbNB3Z/NOhtFGzuuibqaSYbf8WvpRDLxsr6YkoaxIICrusAkUgk679RuRGwgZSmLDGY2v//svYgNuvzIk6bGKl9JHxH2LCabU0uld0rpB2stWZPa8Rk3zHsC1D+l8yE9G6mLFeWMdOjP4Vu9dqzV/GEdVLZ/5KVi3KhfKwFq/3ThsrGi6F++r+mgXx+sabBZi+T+naW4BBl6z2C43fidEkbq8r8F4MV6mQ7JJUfEwwKlLC6pV06aIoy4b4VFOkw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3561.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(396003)(136003)(366004)(39860400002)(376002)(44832011)(186003)(33656002)(71200400001)(316002)(5660300002)(4326008)(2906002)(66446008)(9686003)(6506007)(110136005)(26005)(52536014)(478600001)(55016002)(76116006)(54906003)(83380400001)(64756008)(86362001)(8936002)(66476007)(53546011)(66556008)(7696005)(66946007)(8676002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?Sy9NVVVJTWZsbzlNTWgrbjY2QWJwV3hwRmNqYnl6aEVreCtoa1pxcTZBWDdL?= =?utf-8?B?VlpFbTE1Y1Bpb0JXUlJJcWxOS2NHbU4wSEZ0alcxR1l3eVpWdkVHaWVUN1RX?= =?utf-8?B?WmpjVktidkpPNDZpdjkxejFaNncwNFlrTEt6eS8xRFBkTW1uSCt0RUdiMFJp?= =?utf-8?B?cWNUbnRrQXJXSitObHJodDdhWWNrSVFOemREUFAzdWlvZnpIM1hMdzBFbjdS?= =?utf-8?B?QXVqSTRBdEp4VGhKM2xJY1U3ckxObmNDelRtZnhZRnhuMXE0Z1N5VUNTN3Za?= =?utf-8?B?R0tyWlEvN0tUd1FzdmpNdzhENXI5b0cwTXB2N2dhRFlGOUUvR2lOQjR0ME5Q?= =?utf-8?B?Y2lYd2htTWhWUEtKQlFYOEdlekppc3N3T2MySFNmNUc5Q3pnMy9NL21IWVZK?= =?utf-8?B?dWJkS0VvVWJmajBFM0xPeTBQVU1GZEhHb2xaemJ6NGNENlRYRGRkenpGNXJ2?= =?utf-8?B?Wi9YaEVOTXpqRmNzaVkwc2pxVXBwRTJCN0J6ZEd3c05oaVpoNW1HWGZDRFFo?= =?utf-8?B?Q1ZJc1NTY09GM1hTcTVpTUdDYitTaERjNWp3ZjNsbDdLc0lLRmlUR1FDdE9X?= =?utf-8?B?UEFEbW0zcllTODR3eFZWcVBIbVRxVExjU1A3VGVKdGZac0JXZC94bGhTSUY5?= =?utf-8?B?eVRwaDY2dVVEQ3cvRjAvUGJVMyt2Z1VYbGJTSHVOMXBSS0tka3h0QmtEbXU5?= =?utf-8?B?R0NlK2FuY3UzUmxQYTRMdE1GbTVGL3NQWmtabHA2R1ZoZElpdFNXK1ducTNp?= =?utf-8?B?THNBTm92WlJ5cHlJa1pjRWt1LzFQRWJ3WVdXMDU3alFQd3NXWDk1QU9sTmhI?= =?utf-8?B?NVVzVEpFWWh3T1BlN0dYN1BKbUs5bURweUFPYW5MdUk2VXZPOWZDdVJGQVRT?= =?utf-8?B?cEFkOXBOZGJ5TkRsb1hvK1AvMHRQcm9RUUw2ZVNwZEY1a25yUkw3UFVQaUNQ?= =?utf-8?B?MW1vSFpyL2JCcUw2M3ZIa0QzdjJJTWVsY2RUQmhMOVp6L21iVnBmMXphazdU?= =?utf-8?B?ZHdKcGFXdU0vWU1ZeDdMeTJHdzBaUWdVeWtnNWpSb2hBQVYwRTFuWVBrNGh0?= =?utf-8?B?VU5XNFhaczFPa3AxOUwvUFhKTUVEVHVpYzdXczM2Q1hoWkpaMDVjSFRPand2?= =?utf-8?B?RHBrbCtqZDZ5WE14RERrdzhRVk9pT2FHYUdjTEMrQTVqbUh1cFM4cFNDdUIw?= =?utf-8?B?WWJqVTdUWWJmV3RPQnpFVDVselovbVRsNzF6SmFjVVg0bTd5ODh2Q3NOVHhJ?= =?utf-8?B?bkc4dGs0UUhvdFp0QWlMeXIwdUIwYXdOZmRmUXZzZlpNZTNwaXpSTzlpWDZY?= =?utf-8?B?WUJVMHdXdjNtWnF0Mmc0OHZCeEZ6YnJKbWJMc3Y0N1JzTi9IazlacFB6SUlh?= =?utf-8?B?M2gvSUhjK3FTNWRIY3lOcU43UmdMcUx0Qm4vRXBPU3doZk5KbFFaemtoSGI5?= =?utf-8?B?M3pUT2poU0prUlpvVndlaUpPdWIxZCt6SnFlSDFIOWU2dUlFVjFFMUxYSGUv?= =?utf-8?B?YThTZXVuTEQ0RWlaRUxQT0E4Nk1kMTNnT09KYXNXcGJzVHFzSWNJdUdsMzJE?= =?utf-8?B?SGVoK3E0d3ZTaEJLNUNxaGI3a3lIeVRsMHc5OXM3UWowQVFiYVNTL1dPUFph?= =?utf-8?B?ckNCUFI2VnFCZHFZWUVhdUFyN05wbXlQRnFNQzFPY2h0TWpMNzRHMTdJRjB0?= =?utf-8?B?Tm1wdzBwT2tQWjVvY0JIOU93Zy9pNlNhWGowa0NkeWNFSmRkNUdpcTBTQzF6?= =?utf-8?Q?DAvaRy2sHoNRzG/eYJFRBEq2EJN0axMWOvmZ2d0?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3561.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5a3b5492-8a4d-4de9-eaa7-08d8ccff6dc1
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2021 13:34:30.2347 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: hJKkMpPIBhX4TyW16EKjZS1Y3fAjXKCPakGwOMyJwXyF2Bf1eKVnPM59TRnQhbLe7hDp/2nuKJSJa83op1/4U93K9+DC7W01ZdxcljSr2WE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2841
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/sBQ-g3YbAD0ZUWP27xC7PUZN4g8>
Subject: Re: [tram] A few comments on draft-ietf-tram-stun-pmtud-17.txt
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Feb 2021 13:34:38 -0000

Hi Felipe, authors,

what is the current status of this?

Cheers,

Gonzalo

> -----Original Message-----
> From: Felipe Garrido (fegarrid) <fegarrid@cisco.com>
> Sent: Wednesday, October 28, 2020 18:05
> To: Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>om>; Magnus
> Westerlund <magnus.westerlund@ericsson.com>om>; gorry@erg.abdn.ac.uk;
> tram@ietf.org
> Cc: gorry@abdn.ac.uk
> Subject: Re: [tram] A few comments on draft-ietf-tram-stun-pmtud-17.txt
> 
> Hi Gonzalo,
> 
> We are finalizing the last set of changes to address some additional
> comments and will be publishing a new version of the draft shortly.
> 
> Thanks,
> -Felipe
> 
> On 10/22/20, 8:38 AM, "Gonzalo Camarillo"
> <gonzalo.camarillo@ericsson.com> wrote:
> 
>     Authors, Magnus,
> 
>     what is the status of this?
> 
>     Cheers,
> 
>     Gonzalo
> 
>     > -----Original Message-----
>     > From: Magnus Westerlund <magnus.westerlund@ericsson.com>
>     > Sent: Tuesday, September 22, 2020 14:41
>     > To: gorry@erg.abdn.ac.uk; fegarrid@cisco.com; tram@ietf.org
>     > Cc: gorry@abdn.ac.uk
>     > Subject: Re: [tram] A few comments on draft-ietf-tram-stun-pmtud-17.txt
>     >
>     > Hi,
>     >
>     >
>     > Great to see progress on this. I think this is clearly a step in the right
>     > direction. However, I think there are a couple of integration points that
>     > needs a bit more clarification.
>     >
>     > On Mon, 2020-09-14 at 18:04 +0100, Gorry Fairhurst wrote:
>     > > Thanks for this new revision! It indeed answers many of the issues
>     > > that were identified.
>     > >
>     > > I do still see a few things left that the WG should decide upon, and
>     > > hope this helps:
>     > > ---
>     > > The text says this:"A client MUST NOT send a probe if it does not have
>     > > knowledge that the server supports this specification.  This is done
>     > > either by external signalling or by a mechanism specific to the UDP
>     > > protocol to which PMTUD capabilities are added or by one of the
>     > > mechanisms specified in Section 5."
>     > > - This looks like a strong requirement without saying why this is a
>     > > "MUST NOT".
>     > > - I don't actually understand how this is determined in this spec and
>     > > how this can be extened to other protocols.
>     >
>     > Isn't this as case of SHOULD NOT send, and the probing will fail if there
> are
>     > no responses per the RFC 8899 process? Likely this can quite simply be
>     > connected so that there are handling when the signalling has failed to
>     > correctly handle this.
>     >
>     > > ---
>     > > In section 7:
>     > > This section has added a section that is a cross-reference to sections
>     > > in DPLPMTUD. This does seem like a useful addition (and appropriate).
>     > > Currently this doesn’t really seem to me to have enough detail to
>     > > clearly see how the two sets of text relate, one might have to read
>     > > both to figure out the details, and if that’s the case, maybe it could
>     > > be helpful tp be explained up front in the intriduction?
>     > > ---
>     > > DPLPMTUD contains guidance on flow control and congestion control.
>     > > This doesn’t describe the implications of probing on flow control
> control.
>     > > I’m not sure the current text is enough: 8. Probing and flow control:
>     > > This requirement is out of scope and is not discussed in this document.
>     > > - Do probe packets count as credit to an upper layer protocol using
>     > > this method?  Here are there options: One could be to explain how this
>     > > is done, the easiest mighht be to explain the usage in STUN does not
>     > > require this, or the third: defer to DPLPMTUD saying this applies.
>     >
>     > So to my understanding the STUN probing traffic will be rate controlled.
>     > However, to what rate is not that clear. I don't know if the interaction
>     > between the RFC 8899 state machine and process and this mechanism to
>     > judge how that bounds the prob transmission. My impression would be
> that
>     > for simple probing mechanism RFC 8899 search will trigger the
> transmission
>     > of partiular probe size, and retry it Rc times if response is not arriving
> timely.
>     > These retransmission would be controlled by the RTO in STUN. While
> probing
>     > for an additional size would be governed by RFC 8899 search requesting
>     > probing of a new size. Which I don't find any given limit to. But, it will not
>     > result in more than one packet per RTT unless actual path RTT > RTO (500
>     > ms).
>     >
>     >
>     >
>     > > ---
>     > > “9.  Shared PLPMTU state: This requirement is out of scope and is not
>     > > discussed in this document.”
>     > > - Why is 9. out of scope? ... what does the method do with the
>     > > (PL)PMTU value that it discovers? How is this made available to a user
>     > > of the method and is the method cached in way?
>     > >
>     > > - How does the method relate to the cached value of PMTUD at the
>     > > sender, if that is already running on a platform, doesn't this new
>     > > method mean than the PMTU cache and PTB-updates have to be
>     > > over-ridden, as is the case when using DPLPMTUD with other protocol
>     > stacks?
>     > >
>     > > - Also is it that the discovered (PL)PMTU value can never be cached by
>     > > another usage of STUN? (I may have misunderstood)
>     > >
>     > > ---
>     > > Section 7.  Rev-18 also introduces quite a few typos - but I assume a
>     > > spelling checker will find and help correct these.
>     > > ---
>     > >
>     > > That leaves Section 5:
>     > >
>     > > I still don’t yet see changes in this version to section 5:
>     > >
>     > >
>     > “The PMTUD mechanism described in this document is intended to be
> used
>     > >     by any UDP-based protocols that do not have built-in PMTUD
>     > >     capabilities, irrespective of whether those UDP-based protocols are
>     > >     STUN-based or not. "
>     > > - Please see comments made in the previous last call, about this ID
>     > > not defining this for other UDP-based protocols. At the moment it
>     > > still says this ID applies to other uses of UDP (which I did not see
>     > > explained, nor do I think this is needed). To me, much of the spec
>     > > proposed seems to me to rely upon the STUN multiplexing to sepearate
>     > > the probe packets from data, to receive feedback and to introduce
>     > padding.
>     > > - Please discuss the expected scope of the spec with your WG AD, and
>     > > suggest how to best take section 5 forward.
>     > >
>     >
>     > On this issues, my view is that this document tries to oversell its
> capability.
>     > The probe method can be combined with UDP based protocols that can
> be
>     > multiplexed with STUN on the same port. The considerations that went
> into
>     > RFC
>     > 7983 does need to be considered here in relation to if one can deploy
> this
>     > type of probing messages. So I think you need to make this applicability
>     > clearer.
>     >
>     > Cheers
>     >
>     > Magnus Westerlund
>     >
>     >
>     > ----------------------------------------------------------------------
>     > Networks, Ericsson Research
>     > ----------------------------------------------------------------------
>     > Ericsson AB                 | Mobile +46 73 0949079
>     > Torshamnsgatan 23           |
>     > SE-164 80 Stockholm, Sweden | mailto:
> magnus.westerlund@ericsson.com
>     > ----------------------------------------------------------------------
>     >
>