Re: [manet-dlep-rg] TCP clients, servers, and discovery (WAS: Re: notes DLEP meeting @ IETF88)

"Taylor, Rick" <Rick.Taylor@cassidian.com> Fri, 15 November 2013 13:37 UTC

Return-Path: <rick.taylor@cassidian.com>
X-Original-To: manet-dlep-rg@ietfa.amsl.com
Delivered-To: manet-dlep-rg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 675B311E8185 for <manet-dlep-rg@ietfa.amsl.com>; Fri, 15 Nov 2013 05:37:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.015
X-Spam-Level:
X-Spam-Status: No, score=-1.015 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, MISSING_HEADERS=1.292]
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 GHHsKidKIAa7 for <manet-dlep-rg@ietfa.amsl.com>; Fri, 15 Nov 2013 05:37:46 -0800 (PST)
Received: from mail-dotnet3.eads.net (mail-dotnet3.eads.net [193.56.40.75]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE1411E812A for <manet-dlep-rg@ietf.org>; Fri, 15 Nov 2013 05:37:45 -0800 (PST)
Received: from unknown (HELO fr-gate2.mailhub.intra.corp) ([53.154.16.34]) by mail-dotnet3.eads.net with ESMTP; 15 Nov 2013 14:37:24 +0100
Received: from f8562vs5.main.fr.ds.corp ([10.37.8.22]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Fri, 15 Nov 2013 14:35:45 +0100
Received: from f8561vs4.main.fr.ds.corp ([10.37.8.21]) by f8562vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Fri, 15 Nov 2013 14:35:45 +0100
Received: from SUCNPTEXC01.com.ad.uk.ds.corp ([10.80.73.70]) by f8561vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Fri, 15 Nov 2013 14:34:52 +0100
Received: from SUCNPTEXM01.COM.AD.UK.DS.CORP ([fe80::2543:10a0:fd02:b894]) by SUCNPTEXC01.com.ad.uk.ds.corp ([::1]) with mapi id 14.02.0318.004; Fri, 15 Nov 2013 13:34:51 +0000
From: "Taylor, Rick" <Rick.Taylor@cassidian.com>
Thread-Topic: [manet-dlep-rg] TCP clients, servers, and discovery (WAS: Re: notes DLEP meeting @ IETF88)
Thread-Index: AQHO4fvDOxnM2CwZqEihxE7/87lrqpomRGoA
Date: Fri, 15 Nov 2013 13:34:52 +0000
Message-ID: <23f4eb95-c917-4ed4-a5be-c20acc5b24ef@SUCNPTEXC01.COM.AD.UK.DS.CORP>
References: <979927df-e29f-4d41-b5c6-4c3c0ec70db7@SUCNPTEXC01.COM.AD.UK.DS.CORP> <e65cf55d-2150-4118-8d59-2363da4055a2@SUCNPTEXC01.COM.AD.UK.DS.CORP>
In-Reply-To: <e65cf55d-2150-4118-8d59-2363da4055a2@SUCNPTEXC01.COM.AD.UK.DS.CORP>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.80.23.75]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 15 Nov 2013 13:34:52.0370 (UTC) FILETIME=[76A81B20:01CEE207]
X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-20292.007
X-TM-AS-Result: No--6.983000-0.000000-31
X-TM-AS-User-Approved-Sender: Yes
X-TM-AS-User-Blocked-Sender: No
Cc: "DLEP Research Group (manet-dlep-rg@ietf.org)" <manet-dlep-rg@ietf.org>, "Dowdell, John" <John.Dowdell@Cassidian.com>
Subject: Re: [manet-dlep-rg] TCP clients, servers, and discovery (WAS: Re: notes DLEP meeting @ IETF88)
X-BeenThere: manet-dlep-rg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DLEP Radio Group <manet-dlep-rg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet-dlep-rg>, <mailto:manet-dlep-rg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet-dlep-rg>
List-Post: <mailto:manet-dlep-rg@ietf.org>
List-Help: <mailto:manet-dlep-rg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet-dlep-rg>, <mailto:manet-dlep-rg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Nov 2013 13:37:53 -0000

Okay, I'm wavering on this one.  I've being thinking hard on this, and my opinion is changing.

First off:

Implementation issues are irrelevant in my opinion.  We are all agreed that writing a TCP server or client is pretty much boiler-plate code.  Modems have full TCP stacks, so do routers (I'm ignoring John's 802.15.4 question).

And now my ramblings:

The correct assignment of Server and Client roles should be driven by semantics of the roles, a server normally handles multiple conversations with many clients: HTTP, SNMP, SMTP, etc, etc...

A server also 'serves' information to interested parties: "I have information, come get it" is a well-used paradigm.

But, using these two suggested modes of operation gives two different answers:

Routers (in general) will handle multiple sessions with modems, and modems (in general) will communicate with a single router.  This implies that the Router should be the Server.

However, Modems 'serve' DLEP information to routers; they have information for the router to come ask them about.  This implies that the Modem should be the TCP server.  The modem can decide how many sessions to accept and serve (generally 1).

An important factor that I believe has not yet been addressed is that DLEP capable routers 'want' to create a DLEP session with a modem so they can perform their function, but a modem doesn't really care if anyone is receiving DLEP info.  This leads me to suggest that a router should find out that there is a modem on an interface (it receives the discovery) and it then demands the DLEP session from the modem (i.e. It connects to the server in the modem).

>From a game-theory perspective (bear with me) the modem gets no benefit by connecting to an advertising router, and therefore may not, but a router does gain benefit and therefore can force the session creation by connecting.  Therefore, the router should be the client.

Aaaargh!  I'm now arguing with myself!

Rick
The information contained within this e-mail and any files attached to this e-mail is private and in addition may include commercially sensitive information. The contents of this e-mail are for the intended recipient only and therefore if you wish to disclose the information contained within this e-mail or attached files, please contact the sender prior to any such disclosure. If you are not the intended recipient, any disclosure, copying or distribution is prohibited. Please also contact the sender and inform them of the error and delete the e-mail, including any attached files from your system. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com