Re: [6lo] Barry Leiba's Discuss on draft-ietf-6lo-deadline-time-04: (with DISCUSS and COMMENT)

Charlie Perkins <charles.perkins@earthlink.net> Fri, 31 May 2019 00:00 UTC

Return-Path: <charles.perkins@earthlink.net>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC452120182; Thu, 30 May 2019 17:00:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.114
X-Spam-Level:
X-Spam-Status: No, score=-3.114 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.415, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=earthlink.net; domainkeys=pass (2048-bit key) header.from=charles.perkins@earthlink.net header.d=earthlink.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 4qANmOuRYRFR; Thu, 30 May 2019 17:00:11 -0700 (PDT)
Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) (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 9031B12016F; Thu, 30 May 2019 17:00:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=earthlink.net; s=dk12062016; t=1559260811; bh=Buhl6trRmCGzGmO/U6aKfBFnmPIZ6zsd5WLO Acjnpzg=; h=Received:Subject:To:Cc:References:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type: Content-Transfer-Encoding:Content-Language:X-ELNK-Trace: X-Originating-IP; b=AnsGV921kWZahvxYrSDOarbJeO7qSMxsB0ZRs4EEWESFgg jPf9fW8cyBcWycaKGlTtdA23S1SSczAbMlv/DjV9+Rnog0AAwq8ZM6vOQjNDWHbx4av KB7fck2efdhNLvGdGQ2dlTduUlhLYjzxjnnN2/gVi/AUx+KLHZP9nR4qISHnOIFjUta QNfHrbBf3eyCXzpOKBR0eM5RaS/Umvuj2sWrk3FfKwSv0xamuEM/eDpXIdGS/seBlJd z+ciXfc/dpYyYce52Izwdugl91CD1B2bA9cTR2jKPwWE6T8js4VMHaMessqRoAGplcp Yl1v9Tk7KLTa0vbNIyUHqcdaoRwA==
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=earthlink.net; b=emFMawi/DDHuFOIoRWCzTN5uTs5MX8qxcAHQdWtW5R+QimOWIwh5ubMo5c6O7iKLPqyKUvgynhgLNM4MEQzayC9ILlXUtdQGhW44v6n2felEifWqeTJiD02FzYOOvb3iKcUkFmbZKVtPO7UzW35piLtjIn1DnEDD8X6nX9DqwrBq3ONs+oZWiXEDzew616o+AttYA+biKg1/HNUjU96f//BW4I2JzDu0GEHXcKNYhOdiFaZFzmI9li9WDc5nhk2r9G7P2wXN13Eke1FgpCxm6g+CKmNbdfESLchVEzDbVXmIDhxkvpRZjpbkmCMZf8iCSS0p4P7EMT2XFJhJVeubgQ==; h=Received:Subject:To:Cc:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Content-Language:X-ELNK-Trace:X-Originating-IP;
Received: from [99.51.72.196] (helo=[192.168.1.82]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4) (envelope-from <charles.perkins@earthlink.net>) id 1hWUxt-00069R-Gb; Thu, 30 May 2019 20:00:09 -0400
To: Barry Leiba <barryleiba@computer.org>, The IESG <iesg@ietf.org>
Cc: draft-ietf-6lo-deadline-time@ietf.org, 6lo-chairs@ietf.org, Samita Chakrabarti <samitac.ietf@gmail.com>, Shwetha Bhandari <shwethab@cisco.com>, 6lo@ietf.org
References: <155766926695.31687.17410585533455050681.idtracker@ietfa.amsl.com>
From: Charlie Perkins <charles.perkins@earthlink.net>
Message-ID: <d9f37ba8-e802-8af6-c731-a5407b494334@earthlink.net>
Date: Thu, 30 May 2019 17:00:02 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0
MIME-Version: 1.0
In-Reply-To: <155766926695.31687.17410585533455050681.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956846b590522b13c95a8211e0cd9bd6d6e5843730f01dff3a7350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.51.72.196
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/nv8rUIsFylrMc8RVUsDRd2uZt2g>
Subject: Re: [6lo] Barry Leiba's Discuss on draft-ietf-6lo-deadline-time-04: (with DISCUSS and COMMENT)
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 May 2019 00:00:14 -0000

Hello Barry and all,

I have made some follow-up to your comments below...

On 5/12/2019 6:54 AM, Barry Leiba via Datatracker wrote:
> Barry Leiba has entered the following ballot position for
> draft-ietf-6lo-deadline-time-04: Discuss
...
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-6lo-deadline-time/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> This should be easy to explain and clear up, but I have to ask, as I don’t see
> anything about it in the document: what deters entities from using this with a
> short deadline time in order to get expedited delivery, when they don’t need
> it?  How does this help a network if, ultimately, every transmission specifies
> a very short deadline time?

As mentioned in other email, I agree that we should discuss this 
problem, and I guess the right place would be in the Security 
Considerations.  I think the problem only occurs if pre-emption is 
allowed.  So one possibility would be to mandate that implementations 
SHOULD NOT pre-empt.

Designs for gaining some latency advantage by signaling often seem to 
have this problem.  Maybe there is already language we can borrow for 
clarifying the issue in our draft.

If pre-emption does not occur, then I don't think the network is 
impacted in the way that you suggest.  If every transmission specifies a 
short deadline time, then many or most packets will simply be dropped.


>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> In the Introduction, please expand “BLE” on first use.

Will do.


>
> In “Terminology”, you’re citing RFC 8174, but not usng the new BCP 14
> boilerplate from there.  Please copy/paste the new boilerplate.

Will do.


>
> — Section 5 —
>
> The definition of “TU” is out of order; please move it so it’s in the same
> order in the definitions as in the block.

Will do.


>
> Why is DTL the length *minus 1*?  Doesn’t that invite mistakes?  Is there a
> reason not to make it the length, and to say that 0 is not a valid value?

The reason is to allow 16 hex digits for the deadline time, or 64 bits.  
You are right that this makes implementation more vulnerable to error, 
but I believe the danger here is small.  If this is a minority opinion 
and most people want to have the maximum to be 15 hex digits, we can do 
that.

Regards,
Charlie P.