Re: [tram] Artart telechat review of draft-ietf-tram-stunbis-16

Peter Saint-Andre <stpeter@mozilla.com> Mon, 23 April 2018 03:30 UTC

Return-Path: <stpeter@mozilla.com>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88378126FB3 for <tram@ietfa.amsl.com>; Sun, 22 Apr 2018 20:30:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 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, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 JXF9wf6ylndH for <tram@ietfa.amsl.com>; Sun, 22 Apr 2018 20:30:37 -0700 (PDT)
Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 950A3126DED for <tram@ietf.org>; Sun, 22 Apr 2018 20:30:37 -0700 (PDT)
Received: by mail-it0-x232.google.com with SMTP id e20-v6so8977968itc.1 for <tram@ietf.org>; Sun, 22 Apr 2018 20:30:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=MKZzNFz0qNWfyNolYcI4P5s0xqV+tsMh23zcuitAH1M=; b=H687+YsXsYNnz8f3A0SU4011ewMfQ44BklgW9ATSILuHy5vChEJIKHpiizTBIrFiY4 dNwprLlh0gNBY6/wg44rnJ4DfvA8A1E6YbWKg+5HVbnMSOgEu2EQ1l5MDvF+9yHMFnsp WU/YGpJ3hE1Ax7Vg46jA4ozNJE61y09lwwbBM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=MKZzNFz0qNWfyNolYcI4P5s0xqV+tsMh23zcuitAH1M=; b=dzVMQHHHwbcLrPko6ti4dXZHHiZcASbFH5KQYhe0e8PGI5Qwm0oJaG9m0tFGKZc9DW zeh7rGGwkVnXm/1Zcd9ncU+LgHcLDYyov7W1AbfeDY6U4mYNI1PpWQKQqtp5Z6OXVsxJ 1RCPf2uWPLuCxyKDh3Xbrq2f7uZ4NTb4zRXqzaB3/eUZwSwtp9VtfZeEbTZqLd0olQzh kvT3/oNimweDIz0VWYEwE0xP5QYzWrD5mDj7FkKwMJ/p3vThazjVbwnLjx4mX60LgWTR xYidltecV9csdBpqOGmai2fqKDf30M3pAo3DbjrGyg4pMUu54PFogEQ6A2y3foBvpg8k FXnQ==
X-Gm-Message-State: ALQs6tAc5oDneMLyzuKJqtLWlcnvN+pqxb38FbeFsRtZy2URcWUMbov1 7A1VxGE5glFqFj/RirDrJAV7vw==
X-Google-Smtp-Source: AIpwx48Ta84BuBAdUttmgt0oIkH1LpMrAGHMebsvz2cbscRNS+koHIZASA+mISZbWaqnNeTNAQg4zQ==
X-Received: by 2002:a24:730e:: with SMTP id y14-v6mr13111024itb.45.1524454236939; Sun, 22 Apr 2018 20:30:36 -0700 (PDT)
Received: from aither.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id k141-v6sm3556604ite.41.2018.04.22.20.30.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Apr 2018 20:30:36 -0700 (PDT)
To: Marc Petit-Huguenin <marc@petit-huguenin.org>, art@ietf.org
Cc: draft-ietf-tram-stunbis.all@ietf.org, ietf@ietf.org, tram@ietf.org
References: <152270998513.17947.16209089088681034529@ietfa.amsl.com> <ec1d7013-4886-6f96-21a2-3c758fc633cf@petit-huguenin.org> <c6df754b-8aea-637c-a8bf-7ccadc0d8704@mozilla.com> <6422219a-5c2d-4590-3088-0f1afa3feb8f@petit-huguenin.org> <00ddbc05-2a96-d77e-f260-7d0b3c0f4074@petit-huguenin.org>
From: Peter Saint-Andre <stpeter@mozilla.com>
Message-ID: <5f036c89-07b1-8d9d-cd18-8d9381ef8adf@mozilla.com>
Date: Sun, 22 Apr 2018 21:30:34 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <00ddbc05-2a96-d77e-f260-7d0b3c0f4074@petit-huguenin.org>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/0EgQfO68q0yQKG8WhVwYsS2ViVU>
Subject: Re: [tram] Artart telechat review of draft-ietf-tram-stunbis-16
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Apr 2018 03:30:41 -0000

On 4/21/18 3:39 PM, Marc Petit-Huguenin wrote:

>>>>> Section 6.3.4 states:
>>>>>
>>>>>    o  If the error code is 500 through 599, the client MAY resend the
>>>>>       request; clients that do so MUST limit the number of times they do
>>>>>       this.
>>>>>
>>>>> It is reasonable to provide guidance as to the number of re-sends?
>>>>
>>>> Same issue here, that's a section that is unmodified from RFC 5389. 
>>>
>>> I understand. Now is our chance to fix it. :-)
>>>
>>>>  As long as the client does not enter an endless loop of retransmission, choosing different numbers of re-sends does not affect interoperability.
>>>
>>> Choosing different numbers is OK, but choosing an infinite number is
>>> not. Can we provide guidance as to how many is too many? 10? 50? 100?
>>
>> Well, the text already states that an infinite number of of re-sends is not compliant.  Anyway, I am not sure how to determine a reasonable number, but I'll try.
> 
> I chose 4 as the maximum number of retransmissions.  I based that on error code 508 in TURN that defines a delay of 60 seconds between retransmissions, so we now get a delay of 5 minutes before the client gives up in case of insufficient capacity.  The new text reads like this:
> 
> "o  If the error code is 500 through 599, the client MAY resend the
>     request; clients that do so MUST limit the number of times they do
>     this.  Unless a specific error code specifies a different value,
>     the number of retransmissions MUST be limited to 4."
> 

"SHOULD be limited to 4" seems fine, but MUST is OK too.

Thanks for looking into this and making the fix.

Peter