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

Henning Rogge <hrogge@googlemail.com> Fri, 15 November 2013 13:57 UTC

Return-Path: <hrogge@googlemail.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 C1BB811E813F for <manet-dlep-rg@ietfa.amsl.com>; Fri, 15 Nov 2013 05:57:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
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 I5JlBOm8FT+y for <manet-dlep-rg@ietfa.amsl.com>; Fri, 15 Nov 2013 05:57:38 -0800 (PST)
Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 44C8A11E81A2 for <manet-dlep-rg@ietf.org>; Fri, 15 Nov 2013 05:57:37 -0800 (PST)
Received: by mail-qa0-f45.google.com with SMTP id i13so544134qae.18 for <manet-dlep-rg@ietf.org>; Fri, 15 Nov 2013 05:57:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=ijTwbzZ9sd36O7w3CvHIlLew+Quoo9hq6xgfdFCJbV8=; b=Sv34LvJsllmTgq2M5IPFdiPSF7xOpfrPsnqVwb+3XwABFY23El0sAYvAqF7QVgqZ71 0G3N26hF2bnHPZukTsblrQkU8K5shLoeUx7tAB9d8cvjnIod0Q9YHhfXYbMuBWzCvFwa NcfRCQK1ng6/cpiNICEQF7TnqAzPXDXEF2JNyznDRbmMNOsBgJLDC/m3ai3FbPfH7vGc lFc5c1p7BrVVvSrBppCOPnILkBLEuBvEz/bM3iduZsZ62mHzyXNqy4I3rTEYzB1ClKDG 1UB9qxj2IvWtu1Mqg6naHQUxb8VGUwbrRuW7IYvLXf6YgF6cu+5dQ/4vOQ/VCn1mpPZj Gx3g==
X-Received: by 10.224.65.199 with SMTP id k7mr11130464qai.24.1384523856099; Fri, 15 Nov 2013 05:57:36 -0800 (PST)
MIME-Version: 1.0
Received: by 10.224.36.200 with HTTP; Fri, 15 Nov 2013 05:57:15 -0800 (PST)
In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F98FA5ACDCC@tss-server1.home.tropicalstormsoftware.com>
References: <979927df-e29f-4d41-b5c6-4c3c0ec70db7@SUCNPTEXC01.COM.AD.UK.DS.CORP> <e65cf55d-2150-4118-8d59-2363da4055a2@SUCNPTEXC01.COM.AD.UK.DS.CORP> <23f4eb95-c917-4ed4-a5be-c20acc5b24ef@SUCNPTEXC01.COM.AD.UK.DS.CORP> <38A5475DE83986499AEACD2CFAFC3F98FA5ACDCC@tss-server1.home.tropicalstormsoftware.com>
From: Henning Rogge <hrogge@googlemail.com>
Date: Fri, 15 Nov 2013 14:57:15 +0100
Message-ID: <CAGnRvurpZ26kXHGaSYUNaSHerKH9PWUHHO_K5pr1VY61i0TDUw@mail.gmail.com>
To: Rick Taylor <rick@tropicalstormsoftware.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: "DLEP Research Group (manet-dlep-rg@ietf.org)" <manet-dlep-rg@ietf.org>
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:57:40 -0000

And if the radio is directly (without a switch) connected to an
interface of the router, there is not even a difference between
unicast and multicast in terms of networking overhead.

Henning Rogge

On Fri, Nov 15, 2013 at 2:40 PM, Rick Taylor
<rick@tropicalstormsoftware.com> wrote:
> After a quick rant at a colleague, it has been pointed out that the fewer devices on the network throwing out discovery packets on multicast, the better.
>
> So perhaps the router should be the server.
>
> But, the multi-cast is link-local so there shouldn't be issues with flooding...
>
> Aaargh!
>
> ________________________________________
> From: manet-dlep-rg-bounces@ietf.org [manet-dlep-rg-bounces@ietf.org] on behalf of Taylor, Rick [Rick.Taylor@cassidian.com]
> Sent: 15 November 2013 13:34
> Cc: DLEP Research Group (manet-dlep-rg@ietf.org); Dowdell, John
> Subject: Re: [manet-dlep-rg] TCP clients, servers, and discovery (WAS: Re: notes DLEP meeting @ IETF88)
>
> 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
> _______________________________________________
> manet-dlep-rg mailing list
> manet-dlep-rg@ietf.org
> https://www.ietf.org/mailman/listinfo/manet-dlep-rg
> _______________________________________________
> manet-dlep-rg mailing list
> manet-dlep-rg@ietf.org
> https://www.ietf.org/mailman/listinfo/manet-dlep-rg



-- 
We began as wanderers, and we are wanderers still. We have lingered
long enough on the shores of the cosmic ocean. We are ready at last to
set sail for the stars - Carl Sagan