Re: [Dots] [core] WG Last Call on draft-ietf-core-new-block (Congestion Control)

mohamed.boucadair@orange.com Wed, 03 February 2021 08:15 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: dots@ietfa.amsl.com
Delivered-To: dots@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A1E63A15B2; Wed, 3 Feb 2021 00:15:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.118
X-Spam-Level:
X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.com
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 QBPh3zvDsUOv; Wed, 3 Feb 2021 00:15:12 -0800 (PST)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1C623A15B1; Wed, 3 Feb 2021 00:15:11 -0800 (PST)
Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 4DVvcZ1g8Rz8spq; Wed, 3 Feb 2021 09:15:10 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1612340110; bh=kNH9nckd/4cQZlExKBuTuBQrThYHC3+e+qbDySLQUFI=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=UdWZU2VGTiCzpD/DCJ7JhUbOetuxWfuxRAZpeolSVytwV3GzPRu3AogBW+zdGVrcY mszmgHfJFTKdCJR4nEFqvz975G6SYv+Wb7sDpesaTgu2mnmdU7OVE6BGA2Gi8mHdR9 2Ausra0q+fqAH44xkVVdFRLlDQSOfr4vhiaFAUSq0LAyMSOMeTWVvqshdHd9dpzaVP 4S+8BOipRU5f90rg2Bxl3+fVRF6OKENdONQ3mVbuGeezNkAzyUgd7pusK0m12Xsmd7 6mF35/IVq7vf4um7mW2xW/VstBnnVDTJrO7731fkyLzvT9ocZOyKY/CCmd/7GF1NFB kPtlR8HorF1sQ==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.48]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 4DVvcZ0VFDzCqm4; Wed, 3 Feb 2021 09:15:10 +0100 (CET)
From: <mohamed.boucadair@orange.com>
To: =?iso-8859-1?Q?Christian_Ams=FCss?= <christian@amsuess.com>
CC: "core@ietf.org WG (core@ietf.org)" <core@ietf.org>, "dots@ietf.org" <dots@ietf.org>, "draft-ietf-core-new-block@ietf.org" <draft-ietf-core-new-block@ietf.org>
Thread-Topic: [core] WG Last Call on draft-ietf-core-new-block (Congestion Control)
Thread-Index: AdbZC/aiJQkTFqGDTZuAOZL1HdyQ6wg+A0MA
Date: Wed, 3 Feb 2021 08:15:09 +0000
Message-ID: <15830_1612340110_601A5B8E_15830_95_1_787AE7BB302AE849A7480A190F8B9330315C6397@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <31613_1608714849_5FE30A61_31613_100_2_787AE7BB302AE849A7480A190F8B9330315A17B3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <31613_1608714849_5FE30A61_31613_100_2_787AE7BB302AE849A7480A190F8B9330315A17B3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.245]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/l0qhJ1HPJRL7HugJYTgclzYDyTo>
Subject: Re: [Dots] [core] WG Last Call on draft-ietf-core-new-block (Congestion Control)
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <dots.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dots>, <mailto:dots-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dots/>
List-Post: <mailto:dots@ietf.org>
List-Help: <mailto:dots-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dots>, <mailto:dots-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Feb 2021 08:15:14 -0000

Re-,

FWIW, we significantly updated the congestion control as you can see in: https://tools.ietf.org/html/draft-ietf-core-new-block-06#section-6 

We finally added this text to point to how some parameters can be tweaked by an application: 

      Note: For the particular DOTS application, PROBING_RATE and other
      transmission parameters are negotiated between peers.  Even when
      not negotiated, the DOTS application uses customized defaults as
      discussed in Section 4.5.2 of [RFC8782].  Note that MAX_PAYLOADS,
      NON_MAX_RETRANSMIT, and NON_TIMEOUT can be negotiated between DOTS
      peers as per [I-D.bosh-dots-quick-blocks].

We believe that we addressed your initial concern, but having an ACK would be appreciated. Thanks. 

Cheers,
Jon & Med

> -----Message d'origine-----
> De : mohamed.boucadair@orange.com
> [mailto:mohamed.boucadair@orange.com]
> Envoyé : mercredi 23 décembre 2020 10:14
> À : Christian Amsüss <christian@amsuess.com>om>; draft-ietf-core-new-
> block@ietf.org
> Cc : core@ietf.org WG (core@ietf.org) <core@ietf.org>rg>; dots@ietf.org
> Objet : RE: [core] WG Last Call on draft-ietf-core-new-block
> (Congestion Control)
> 
> Re-,
> 
> You are completely right that the default probing-rate is to be
> increased for the DOTS case. FYI, this is why we went with the
> following in RFC8782:
> 
>       |  Given that the size of the heartbeat request cannot exceed
>       |  ('heartbeat-interval' * 'probing-rate') bytes, 'probing-
> rate'
>       |  should be set appropriately to avoid slowing down heartbeat
>       |  exchanges.  For example, 'probing-rate' may be set to 2 *
>       |  ("size of encrypted DOTS heartbeat request"/'heartbeat-
>       |  interval') or (("size of encrypted DOTS heartbeat request" +
>       |  "average size of an encrypted mitigation
> request")/'heartbeat-
>       |  interval').  Absent any explicit configuration or inability
> to
>       |  dynamically adjust 'probing-rate' values (Section 4.8.1 of
>       |  [RFC7252]), DOTS agents use 5 bytes/second as a default
>       |  'probing-rate' value.
> 
> We also allow DOTS peers to negotiate the transmission parameters
> (and probing rate) with the following as default:
> 
>    "The RECOMMENDED values of
>    transmission parameter values are 'ack-timeout' (2 seconds), 'max-
>    retransmit' (3), and 'ack-random-factor' (1.5).  In addition to
> those
>    parameters, the RECOMMENDED specific DOTS transmission parameter
>    values are 'heartbeat-interval' (30 seconds) and 'missing-hb-
> allowed'
>    (15)."
> 
> We avoided to include a pointer to these details as these are
> application-specific and that, even if the draft is motivated by the
> DOTS use case, other applications can make use of the new block
> functionality.
> 
> For NSTART, we already have the following:
> 
>   " NSTART will also need to be increased from the default
>    (1) to get faster transmission rates."
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Christian Amsüss [mailto:christian@amsuess.com] Envoyé :
> mercredi
> > 23 décembre 2020 06:01 À : draft-ietf-core-new-block@ietf.org
> > Cc : core@ietf.org WG (core@ietf.org) <core@ietf.org>rg>;
> dots@ietf.org
> > Objet : Re: [core] WG Last Call on draft-ietf-core-new-block
> >
> > * Also on parameters: This document is describing flow control
> stuff
> >   around a situation CoAP was not originally designed for. Wouldn't
> it
> >   make sense to include a set of parameters (PROBING_RATE,
> > MAX_LATENCY,
> >   ACK_TIMEOUT) that's suitable for the DOTS use case? I doubt that
> >   PROBING_RATE will be left to 1 byte/second for any DOTS
> application
> >   using this (for sending 10KiB in the initial 10-package
> MAX_PAYLOADS
> >   burst would mark that connection as unusable for about 3 hours if
> > they
> >   all get lost), so better give justifiable numbers here than rely
> on
> >   implemnetors to come up with unreviewed numbers or disregard
> >   PROBING_RATE altogether.
> >
> >   I don't know if it needs additional justification, but an
> increased
> >   N_START may be justifiable there.
> >

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.