Re: [manet] Last call ending

Lou Berger <lberger@labn.net> Fri, 26 January 2018 00:33 UTC

Return-Path: <lberger@labn.net>
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE83412D838 for <manet@ietfa.amsl.com>; Thu, 25 Jan 2018 16:33:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 6h_bm3u9ynhE for <manet@ietfa.amsl.com>; Thu, 25 Jan 2018 16:33:05 -0800 (PST)
Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) (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 1696912D832 for <manet@ietf.org>; Thu, 25 Jan 2018 16:33:05 -0800 (PST)
Received: from CMOut01 (unknown [10.0.90.82]) by gproxy9.mail.unifiedlayer.com (Postfix) with ESMTP id 852DA1E06CA for <manet@ietf.org>; Thu, 25 Jan 2018 17:33:01 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id 2oYx1x00V2SSUrH01oZ0VR; Thu, 25 Jan 2018 17:33:01 -0700
X-Authority-Analysis: v=2.2 cv=Rf/gMxlv c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=RgaUWeydRksA:10 a=48vgC7mUAAAA:8 a=pGLkceISAAAA:8 a=B5tPVyTTY1-nc6APauUA:9 a=UrZQH8nvgS2ObaNg:21 a=ApypdAytk2UcYvS6:21 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=QSGBUVwFBXPh6mrPe7MoPsBt/5ySQJT0elJCOakQiXQ=; b=DxqIBF6qZ4H+2lLj96npf+t8mC QBmyS3wQuJqveWysYHzdI5WMWEIqobUD1s/NBU71JcC2IxRqZTaOxNykUsXbz26Jh6Gp+sk+Cuhts Mjr6740JpwvsELa418HnXCzr4;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:49946 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from <lberger@labn.net>) id 1eerwv-002F8R-LT; Thu, 25 Jan 2018 17:32:57 -0700
To: "Wiggins, David - 0665 - MITLL" <David.Wiggins@ll.mit.edu>, Justin Dean <bebemaster@gmail.com>, MANET IETF <manet@ietf.org>
References: <CA+-pDCeA5z0+YE4yXYymkWo8vNthp2k6Pt9nHr32z+ApCLum_A@mail.gmail.com> <020E5EA0-7A6B-46D1-9363-640E3FBBA0ED@ll.mit.edu>
From: Lou Berger <lberger@labn.net>
Message-ID: <b4faeff9-6fce-cf6c-83a5-ed1db17430e3@labn.net>
Date: Thu, 25 Jan 2018 19:32:55 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <020E5EA0-7A6B-46D1-9363-640E3FBBA0ED@ll.mit.edu>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.86.101
X-Exim-ID: 1eerwv-002F8R-LT
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net ([IPv6:::1]) [100.15.86.101]:49946
X-Source-Auth: lberger@labn.net
X-Email-Count: 3
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/fM3XbTnhZF7yj9S0v6i6xzQWqrw>
Subject: Re: [manet] Last call ending
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Mobile Ad-hoc Networks <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/manet/>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jan 2018 00:33:08 -0000


On 1/25/2018 10:07 AM, Wiggins, David - 0665 - MITLL wrote:
>
> I think the latency extension is in reasonable shape.  I agree with 
> all of Vicky’s recent comments.
>
> Here are some comments on the Multi-Hop extension.
>
> Section 3.1
>
> “…each hop represents a transmission and the number of hops is
>
> equal to the number of transmissions required to go from a router
>
> connected modem to the destination's connected modem.”
>
> So hops are counted starting at the modem that is the DLEP peer of the 
> router.
>
yes, that's the intent.

> But then:
>
> “The minimum number of hops is 1, which represents the router's 
> locally connected modem.”
>
how about "which represents the *transmission* by the router's locally 
connected modem."?

> If counting starts at that modem, wouldn’t hop count be 0 for the modem?
>
I don't understand this.  Perhaps you mean for the hop between the 
router and the modem?  This extensions isn't intended to count router to 
modem hops.

>   If it’s 1, this seems to mean that the (typically) wired link 
> between the router and the modem is being counted.
>
How so?  1 means a single transmission over the modem attached media 
(RF) channel .

> I think the two quotes above are inconsistent about whether this first 
> link counts as a hop. If the hop count was meant to convey 
> over-the-air hops, then the router’s locally connected modem should 
> have a hop count of 0.
>
There is no destination for the locally connected modem, so zero would 
never be reported.  In what case do you see zero being reported?

> “A value of zero (0) is used to indicated that processing of a Hop
>
> Control action, see Section 3.2, has resulted in a destination no
>
> longer being reachable.”
>
> I would rather not have this special case. Just leave it to 
> Destination Down to convey loss of reachability.  I’ve worked on 
> systems that had multiple different ways of indicating a node was 
> down, and it leads to bugs, especially when the down indications are 
> not closely synchronized.  Part of the system thinks a node is up, 
> part thinks it’s down, and chaos ensues.
>
I'd actually expect both a Destination Down, per normal processing which 
is not modified by this document, and a  Link Characteristics Request 
Message.  This is so there is consistent processing of  the Hop Control 
Data Item on both router and modem.  Otherwise there how will a router 
know that a particular Hop Control request has completed.  Having just a 
Destination Down would mean that the router would have to infer that 
this was due to the hop control when in fact it may be due to just some 
transitory affect.  In my experience leaving things to inference is a 
bad transaction model and leads to race condition bugs. So I'd prefer to 
leave as is. I've added a note to make it clear that the Destination 
Down is still sent. specifically:
   Note that
   normal DLEP processing is not otherwise modified by this document, this
   includes the generation of Destination Down messages.

> Section 3.2 paragraph 4
>
> “Once the change is made, or fails or is rejected, the modem
>
> MUST respond with a Link Characteristics Request Message…”
>
> Should this have said Response Message?
>
yes

> Section 3.2 paragraph 5
>
> I think a Session Update message should be replied to with a Session 
> Update Response, and a Link Characteristics Request message with a 
> Link Characteristics Response.  The text has both of these being 
> replied to with a Link Characteristics Request message.
>
What information would you like carried in the Session Update Response 
message?  Note that a reset may result in a destination specific change.

> Sections 3.2.2 Terminate and 3.2.3 Direct Connection
>
> These seem to be a way for the router to tell the modem how important 
> it is to be able to communicate with specific destinations.
>
I see this as the way to reverse/undo a 'Direct Connection'.
>
> If that was the motivation, perhaps a more direct expression of that 
> information would be better.  For example, the router could provide a 
> list of destinations, ordered by importance.  I worry that the router 
> giving low-level directions to the modem about which links to maintain 
> might be difficult or suboptimal for some radios.
>
How about:
OLD
    It indicates
     that the modem SHOULD attempt to terminate communication
     with the destination identified in the message.
NEW
    It indicates that a direct connection is no longer needed with the
    the destination identified in the message.
>
> Section 3.2.4 Suppress Forwarding
>
> What exactly is meant by suppressing multi-hop forwarding here?  Is it:
>
> a) If the router sends data (over the data plane) to a destination, 
> and that destination has a hop count > 1, the directly connected modem 
> should drop the data.
>
> b) The modem should discontinue forwarding of all data whose 
> destination is more than one hop away, regardless of where the data 
> came from.  E.g., the modem might be running a manet protocol, and the 
> data could come over-the-air from another modem.
>
> c) something else?
>
> I think it’s probably a),
>
I read it as (a) and (b).  This does imply that the modem in a manet may 
need to alter it's route advertisement in that manet.

> but if so, couldn’t the router arrange its forwarding tables to drop 
> such packets itself instead of asking the modem to do it?
>
That doesn't cover race conditions in case (a) or case (b) at all.

Thank you for the comments!
Lou
>
> Thanks,
>
> David
>
> *From: *manet <manet-bounces@ietf.org> on behalf of Justin Dean 
> <bebemaster@gmail.com>
> *Date: *Tuesday, January 23, 2018 at 11:30 AM
> *To: *MANET IETF <manet@ietf.org>
> *Subject: *[manet] Last call ending
>
> Working group last call is ending on both
>
> https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-latency-extension/
>
> https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-multi-hop-extension/
>
> Please get your comments in.
>
> Justin Dean
>