[conex] Problem solved by draft-ietf-conex-mobile-00?

"Scharf, Michael (Michael)" <michael.scharf@alcatel-lucent.com> Wed, 01 August 2012 22:05 UTC

Return-Path: <michael.scharf@alcatel-lucent.com>
X-Original-To: conex@ietfa.amsl.com
Delivered-To: conex@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 550DA11E8195 for <conex@ietfa.amsl.com>; Wed, 1 Aug 2012 15:05:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.963
X-Spam-Level:
X-Spam-Status: No, score=-9.963 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id im7cyeB9nLj8 for <conex@ietfa.amsl.com>; Wed, 1 Aug 2012 15:05:52 -0700 (PDT)
Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 93C4711E817E for <conex@ietf.org>; Wed, 1 Aug 2012 15:05:52 -0700 (PDT)
Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q71M5mT4017207 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <conex@ietf.org>; Thu, 2 Aug 2012 00:05:49 +0200
Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.55]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Thu, 2 Aug 2012 00:05:48 +0200
From: "Scharf, Michael (Michael)" <michael.scharf@alcatel-lucent.com>
To: "conex@ietf.org" <conex@ietf.org>
Date: Thu, 02 Aug 2012 00:05:46 +0200
Thread-Topic: Problem solved by draft-ietf-conex-mobile-00?
Thread-Index: Ac1wMc2G9E8UBNpHSfy68oLDkVsw0A==
Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E891A9BBD62@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: de-DE, en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13
Subject: [conex] Problem solved by draft-ietf-conex-mobile-00?
X-BeenThere: conex@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Congestion Exposure working group discussion list <conex.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/conex>, <mailto:conex-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/conex>
List-Post: <mailto:conex@ietf.org>
List-Help: <mailto:conex-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/conex>, <mailto:conex-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Aug 2012 22:05:53 -0000

I've not followed that draft in the past, sorry about that. But reading through it right now, I have a hard time of understanding it.

The use cases in section 3.1, 3.2, 3.3, and 3.4 do not seem to be very different to other access networks, except that they are described here in non-IETF terminology.

Also, I don't understand what is specific to mobile networks in Figure 2, 3, and 4. Figure 2 is basically about running conex outside the mobile network and thus not much specifc to mobile. Figure 3 seems to be an end-to-end path over the Internet, which is a full conex deployement and thus not specific to mobile neither.

The most interesting use case for partial deployment seems to be Figure 4. But in that case the document does not explain how conex would be terminated at the edge router of the mobile network (P-GW), and what would be the specific advantage of using this partial deployment in a 3GPP network.

I do understand that Wifi offloading would be a specific use case for mobile networks. To me, this looks similar to congestion-aware routing. But that use case requires a more detailed description how conex information would be used, and under which constraints it can actually be used. For instance, it is unclear to me whether dynamic congestion data as exposed by conex is robust enough for triggering handovers. This would really benefit from some real-world data. Congestion-aware routing does not come without risk, imho.

Thanks

Michael