IETF Logo Mail Archive

Re: [dispatch] draft-asveren-dispatch-http-overload-control

"Asveren, Tolga" <tasveren@rbbn.com> Sun, 15 April 2018 17:06 UTC

Return-Path: <tasveren@rbbn.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39032128954 for <dispatch@ietfa.amsl.com>; Sun, 15 Apr 2018 10:06:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.09
X-Spam-Level:
X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=sonusnetworks.onmicrosoft.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 SP2PR_JRhomk for <dispatch@ietfa.amsl.com>; Sun, 15 Apr 2018 10:05:59 -0700 (PDT)
Received: from us-smtp-delivery-181.mimecast.com (us-smtp-delivery-181.mimecast.com [63.128.21.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7FA9126C19 for <dispatch@ietf.org>; Sun, 15 Apr 2018 10:05:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-rbbn-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=mosyzjN4rXOFw6ccAayd5YzYY7y4BJVhb/aSku/OzFc=; b=E+whBqyCHIEq8oq7gIfqsO6HkQQ+SDaHMiG3rb/bWP/YRSiyY2buJIIPoNdJhnCyJU5/z+h51B8wZFbsBd4n1BFKNuL/QgmAaQ1zlv9znN/Q2pbLCzeYy1vnp5qGKcgqe56Oztm8xN9zfrKxbYXv8TikweX43/EwQK1Kr7qkQKY=
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03lp0056.outbound.protection.outlook.com [216.32.180.56]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-76-y0Lpu-sqPWubMhQLKPUbXw-1; Sun, 15 Apr 2018 13:05:56 -0400
Received: from CY4PR03MB3160.namprd03.prod.outlook.com (10.171.245.165) by CY4PR03MB3221.namprd03.prod.outlook.com (10.171.244.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.675.14; Sun, 15 Apr 2018 17:05:53 +0000
Received: from CY4PR03MB3160.namprd03.prod.outlook.com ([fe80::d8f0:24ac:4222:be23]) by CY4PR03MB3160.namprd03.prod.outlook.com ([fe80::d8f0:24ac:4222:be23%13]) with mapi id 15.20.0675.014; Sun, 15 Apr 2018 17:05:53 +0000
From: "Asveren, Tolga" <tasveren@rbbn.com>
To: Cullen Jennings <fluffy@iii.ca>
CC: "dispatch@ietf.org" <dispatch@ietf.org>
Thread-Topic: [dispatch] draft-asveren-dispatch-http-overload-control
Thread-Index: AdPUIfcZ235QencRQ2mmphW2gQTp5wAmtu8AAAdYtmA=
Date: Sun, 15 Apr 2018 17:05:53 +0000
Message-ID: <CY4PR03MB31609334942E5B3A04EBC4E0A5B10@CY4PR03MB3160.namprd03.prod.outlook.com>
References: <CY4PR03MB3160F7165D883F529D7DB499A5B20@CY4PR03MB3160.namprd03.prod.outlook.com> <3E8C4615-78DE-4C45-95F2-D77856BDB7BC@iii.ca>
In-Reply-To: <3E8C4615-78DE-4C45-95F2-D77856BDB7BC@iii.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [73.29.251.142]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR03MB3221; 7:xxLnOIESnLE2QJHDvA5jq65Qs3cvwNaYmWTy/OSLSU3ASZkxcosiiAmRiMRDp6hlYTeltqQ0AeWtylrazj2DT+UdiLIa/6KGtAGNesiscKoCh+uPqnCOkL7i+l/j9qXqJ+rwn/eD0c8vdVCC1dduIWCiXIDB0Qu5jR2TVIQ2VOxMVJ13dHXawdfhPKB3DVzyV5/hpT8V01ji8YW1p8YO9ID9iyTiXBSI6DF7IU44HBeZVBcEzfHIZTc1XW+pWvKd; 20:ZvtvqWFwvLEQEKWiy+72425ChedEw76F47xjMqzN3MNkvo3uH/M6t66Bk5/i3ydnpQ1LvcFXAuylnJ/7cnqcyien9SlXJw5eYACDfMHH90w+iQI5WrpAlht20sVfLoyCh3YwjOAhkF7hBsRolomZyyXsWl9wTxCtP5pmEozw/PA=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:CY4PR03MB3221;
x-ms-traffictypediagnostic: CY4PR03MB3221:
x-microsoft-antispam-prvs: <CY4PR03MB322171531EF166784591E991A5B10@CY4PR03MB3221.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(35073007944872)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231232)(944501327)(52105095)(3002001)(93006095)(93001095)(10201501046)(6041310)(20161123564045)(20161123558120)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:CY4PR03MB3221; BCL:0; PCL:0; RULEID:; SRVR:CY4PR03MB3221;
x-forefront-prvs: 0643BDA83C
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39850400004)(346002)(39380400002)(396003)(376002)(366004)(199004)(189003)(4326008)(19609705001)(316002)(6246003)(97736004)(2906002)(81156014)(81166006)(478600001)(6306002)(9686003)(236005)(66066001)(486006)(54896002)(55016002)(8936002)(446003)(74316002)(53936002)(8676002)(186003)(476003)(25786009)(26005)(11346002)(53546011)(5660300001)(6916009)(86362001)(102836004)(966005)(3660700001)(76176011)(7736002)(33656002)(229853002)(59450400001)(6436002)(3280700002)(6506007)(106356001)(5250100002)(7696005)(2900100001)(99286004)(606006)(105586002)(790700001)(6116002)(3846002)(14454004)(68736007); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR03MB3221; H:CY4PR03MB3160.namprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
x-microsoft-antispam-message-info: xoFn69g9VbrGfTkAybXOZwBrOmUKS8d5JUCgRUMqU4NPQqkiI7qkooX86wCqIIUmG97kalgbOzZC0PJY4Qu/7OJBznNljkNCjvYSS6boHk57agAbG85mozUva6MuIvaExkNKL6gZJ9bDXbvA2GLlhJMYJ5EQtgxXOfDbWq6MBcTE/xyTXMA2m721CG00+SXD
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 89aeab86-1247-4e6d-364e-08d5a2f3258a
X-OriginatorOrg: rbbn.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 89aeab86-1247-4e6d-364e-08d5a2f3258a
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2018 17:05:53.2266 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR03MB3221
X-MC-Unique: y0Lpu-sqPWubMhQLKPUbXw-1
Content-Type: multipart/alternative; boundary="_000_CY4PR03MB31609334942E5B3A04EBC4E0A5B10CY4PR03MB3160namp_"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/T5LqMpQcZPUOdkfAlyX-ZLFEZ1M>
Subject: Re: [dispatch] draft-asveren-dispatch-http-overload-control
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 15 Apr 2018 17:06:02 -0000

How to handle that would be somewhat implementation dependent but it probably would be a good idea to mention about it in the draft and also list a few choices. A basic option would be not to use a server for retries/retransmissions (unless it is required because the application protocol is stateful across multiple requests). There are more intelligent schemes as well, e.g. determine the maximum rate based on traffic rate/drop rate at the time of receipt/processing of the drop rate value and use it for all requests toward that server until a new drop rate is received.

This issue is generic for any “drop rate based” overload control (so it applies for SIP as well in the context of RFC7339).

Thanks,
Tolga

From: Cullen Jennings <fluffy@iii.ca>
Sent: Sunday, April 15, 2018 9:23 AM
To: Asveren, Tolga <tasveren@rbbn.com>
Cc: dispatch@ietf.org
Subject: Re: [dispatch] draft-asveren-dispatch-http-overload-control

________________________________
NOTICE: This email was received from an EXTERNAL sender
________________________________


If the client finds out it should use a 50% drop rate. How does that interact with retries and retransmissions on the client? I’m just looking for a bit more detail on what the client does once it knows a given set of requests should have a 50% drop rate.



On Apr 14, 2018, at 12:57 PM, Asveren, Tolga <tasveren@rbbn.com<mailto:tasveren@rbbn.com>> wrote:

I just submitted draft-asveren-dispatch-http-overload-control, which specifies a generic overload control mechanism for HTTP/HTTPS applications.

https://www.ietf.org/id/draft-asveren-dispatch-http-overload-control-00.txt


I would appreciate any feedback (as a first step mainly about whether this is something people would be interested in).

Thanks,
Tolga
_______________________________________________
dispatch mailing list
dispatch@ietf.org<mailto:dispatch@ietf.org>
https://www.ietf.org/mailman/listinfo/dispatch

v2.23.0 | Report a Bug | By Email