Re: [manet] next version of pause extension

Rick Taylor <rick@tropicalstormsoftware.com> Thu, 09 November 2017 16:25 UTC

Return-Path: <rick@tropicalstormsoftware.com>
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 C611C126557 for <manet@ietfa.amsl.com>; Thu, 9 Nov 2017 08:25:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 nOqdZYXPntqp for <manet@ietfa.amsl.com>; Thu, 9 Nov 2017 08:25:09 -0800 (PST)
Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA5B11201F2 for <manet@ietf.org>; Thu, 9 Nov 2017 08:25:08 -0800 (PST)
Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d]) by tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d%10]) with mapi; Thu, 9 Nov 2017 16:24:45 +0000
From: Rick Taylor <rick@tropicalstormsoftware.com>
To: Henning Rogge <hrogge@gmail.com>
CC: "lberger@labn.net" <lberger@labn.net>, "manet@ietf.org" <manet@ietf.org>
Thread-Topic: [manet] next version of pause extension
Thread-Index: AQHTWGKbJRgCW8iMokOj3K8ORHF9TaMKg0aAgAAJVYCAAWkbAIAARAog
Date: Thu, 09 Nov 2017 16:24:43 +0000
Message-ID: <38A5475DE83986499AEACD2CFAFC3F9801D322C8B6@tss-server1.home.tropicalstormsoftware.com>
References: <ffb93183-3ebd-39f2-4ca4-3a1b0e737146@labn.net> <CAGnRvuo2=OoHZPDWuvo94AnWJCHXyvOU9YGUSpNyEsxeSR2epw@mail.gmail.com> <9fe45b7b-7d4a-1ff8-09b2-9d0048326081@labn.net> <1510151671.2149.11.camel@tropicalstormsoftware.com> <CAGnRvuqwWZdmobjucitX-2vMZeDZaKN1e33LqTpE_E3g03xz5w@mail.gmail.com>
In-Reply-To: <CAGnRvuqwWZdmobjucitX-2vMZeDZaKN1e33LqTpE_E3g03xz5w@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/zLDgyrkg5m50nUoy3gsCr8yZbHc>
Subject: Re: [manet] next version of pause extension
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: Thu, 09 Nov 2017 16:25:11 -0000

Comments inline...

> -----Original Message-----
> From: Henning Rogge [mailto:hrogge@gmail.com]
> Sent: 09 November 2017 12:07
> To: Rick Taylor
> Cc: lberger@labn.net; manet@ietf.org
> Subject: Re: [manet] next version of pause extension
> 
> On Wed, Nov 8, 2017 at 3:34 PM, Rick Taylor
> <rick@tropicalstormsoftware.com> wrote:
> > Lou, Henning,
> > I just missed the submission deadline for LIDs, but I have a
> > version-02 ready to go when the window reopens on the 11th.
> 
> I think the last version we discussed had both the ability to open "new
> namespaces" for links that don't have real MAC addresses and allow multiple
> "versions/flows/types" of neighbors to the same MAC address, e.g. to
> announce two different QoS classes to the same neighbor.
>

Yes, the new version of LIDs is greatly simplified: One just adds a 'Destination beyond this MAC' identifier.  I've been lucky that LIDs fits very easily alongside 8175 as all its supporting data items and messages already exist, I just need to add one extra bit of information.

Queue and Flows however are an altogether more complicated problem.  Yes, the answer is probably a QueueId dataitem to discriminate between the egress queues on the local modem, but there still needs to be a "These are my queues" announcement (complex), and even then I'm not sure that covers all the potential use-cases!

Are we discussing:

* The local modem classifies egress traffic into more than one egress queue, *no matter* what destination it goes to?  In which case the metrics are {per-Destination,per-Queue}, and the control is per-Queue

* The local modem maintains one egress queue for each destination? In which case we have metrics per-Queue and control per-Queue, but some kind of Queue-to-Destination mapping.

* Both of the above?  In which case I'm going to suggest we don't have the building blocks in place yet to address this!

One thing that is starting to crystalize in my mind is that it's all about transmit queues, any receive queueing that occurs should be transparent to the DLEP session for simplicity's sake.

Lots to discuss, but I think we need to try to get a handle on the use-cases before we talk at cross-purposes.

Lou, can you detail what your use-case is for Pause and DiffServ CW?

Rick