Re: [sipcore] Session-timer: Result below an acceptable value

OKUMURA Shinji <ietf.shinji@gmail.com> Sat, 06 October 2018 07:51 UTC

Return-Path: <ietf.shinji@gmail.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4B6130E48 for <sipcore@ietfa.amsl.com>; Sat, 6 Oct 2018 00:51:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1
X-Spam-Level:
X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 l6byWs0GsdEa for <sipcore@ietfa.amsl.com>; Sat, 6 Oct 2018 00:51:03 -0700 (PDT)
Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (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 283F2130DD6 for <sipcore@ietf.org>; Sat, 6 Oct 2018 00:51:03 -0700 (PDT)
Received: by mail-pl1-x631.google.com with SMTP id f8-v6so7842737plb.2 for <sipcore@ietf.org>; Sat, 06 Oct 2018 00:51:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=g3e3lWeYJEhxfjunUaa0o23aC+xY86ZwjI26LSYz0yo=; b=q+ozHiPalx7iiQ4+Tu9mgOE0SYLKgEdi2FSM4l0HTn6Y30WKszIBteeu7ngaLGFDxB XDeYmMh+jfQiJZJnKaZ330nVi7cJHh4TgRbMPtFqJ+lJmze+fGBup0BsNzBYHnt5wLI3 OyXSC9HOst52Po0nvkh66O2F9Fou9C8KO8u/EW0FBf+plZrEjCHtWLy/VRgc5KxPqhJs FSwmevxoGj2PQb0rr/nNgrQtmhXGN7wemq6x6jLc2pH7ZYSAdfcuPE9FrjK7Zzxrs92H LLt71DlE0yS0PjUWq6XgjEGRUtlxfsAB503ZwFj0NKLt1xtC05XLeDCDsWPMKzeUrya2 RS4A==
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; bh=g3e3lWeYJEhxfjunUaa0o23aC+xY86ZwjI26LSYz0yo=; b=tRRICtXJHD7SoCq7PZkKuwFOUnXKXgUWDXT/twv/oV56pJCe8dgaU7t7B99Wb2xxdq XV0cx/EUBAFdsBEqfkbe1IlJjZPFR4cKYW5RuTXp1RbmY/Be320RCIyE52ZxoDykoDi9 b+kRTrP0n8oEjcaEV/G1LCy7vkamdvSOhymQ7CqgEB2OqNIgg3EI38joSqChsTs61Wtb WSs6ryYCTC2z1Cl94KIwoXRZx0AUvxKUIPdEdVofppKu50wDkqk6mz75Q7P3TgJbtEt6 QQF7Qqnu3KFTaFcmPWFJ95s2fU+86HBTp+herPw/zks4yHwW1TYfxaORpcYy8KJDk4zG wXBg==
X-Gm-Message-State: ABuFfohYEhB5lCyXk53lGHuNnpo7WQOUojgV4tCn6kaeHPyz6bg+rTNX NZqUekmqMqxT2A6dNrpwQKw=
X-Google-Smtp-Source: ACcGV61nXorUDsxWKUObUsGsjIwuHuloq2aUR1L/9lz9K9ZACS0a9Xoo2Ye/G/qSu3Rvgcb7N/jImg==
X-Received: by 2002:a17:902:bcc2:: with SMTP id o2-v6mr15138239pls.22.1538812262659; Sat, 06 Oct 2018 00:51:02 -0700 (PDT)
Received: from [192.168.128.64] (61.245.63.35.er.eaccess.ne.jp. [61.245.63.35]) by smtp.gmail.com with ESMTPSA id u65-v6sm16821703pfb.144.2018.10.06.00.51.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 06 Oct 2018 00:51:02 -0700 (PDT)
To: SIPCORE <sipcore@ietf.org>
Cc: Christer Holmberg <christer.holmberg@ericsson.com>, "roland.jesske@web.de" <roland.jesske@web.de>, Roman Shpount <roman@telurix.com>
References: <VI1PR07MB478264B6B2F31F25BF46EDE093EA0@VI1PR07MB4782.eurprd07.prod.outlook.com> <5eaf2341-dc1f-4241-b0e4-99ad1737d753@email.android.com> <VI1PR07MB4782BF5E160BCA2B56D95BA293EA0@VI1PR07MB4782.eurprd07.prod.outlook.com>
From: OKUMURA Shinji <ietf.shinji@gmail.com>
Message-ID: <c0937619-589a-e459-fdbe-dde4cf8a5082@gmail.com>
Date: Sat, 06 Oct 2018 16:50:56 +0900
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <VI1PR07MB4782BF5E160BCA2B56D95BA293EA0@VI1PR07MB4782.eurprd07.prod.outlook.com>
Content-Type: multipart/mixed; boundary="------------420F174C8C31ADF38815ECC5"
Content-Language: en-US
X-Antivirus: Avast (VPS 181005-0, 2018/10/05), Outbound message
X-Antivirus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/GQ5KmmkuN14HYvPbbb13CDjEkLg>
Subject: Re: [sipcore] Session-timer: Result below an acceptable value
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 06 Oct 2018 07:51:06 -0000

Hi,

If a proxy decreases the S-E, the next proxy is more likely to reject
the request by 422.
So I think that a proxy should adjust the Min-SE rather than decrease
the S-E.
And ultimately, a UAS should decrease the S-E as low as possible after
considering it's own wishes.

Regards,
Shinji

On 2018/10/04 22:33, Christer Holmberg wrote:
> Hi,
>
>
> The UAS is not allowed to include Min-SE to begin with (unless it sends a 422 response).
>
>
> The UAS is currently allowed to reduce the S-E value in the response, as long as it it's larger than the Min-SE value in the corresponding request. My suggestion would be to say that a UAS SHOULD NOT reduce the S-E. Again, assuming the proxies know better how often they want session refreshes, there is no need for the UAS to reduce the value.
>
>
> Regards,
>
>
> Christer
>
>
>
> ________________________________
> From: roland.jesske@web.de <roland.jesske@web.de>
> Sent: Thursday, October 4, 2018 4:21 PM
> To: Christer Holmberg
> Cc: Roman Shpount; OKUMURA Shinji; SIPCORE
> Subject: Re: [sipcore] Session-timer: Result below an acceptable value
>
> Hi
> Reading this. I understand that the proxy should be allowed to increase the Min SE.
> For my understanding.
> Following that the UAS cannot lower it again. Correct?
> That would be my understanding.
>
> Best Regards
> Roland
>
> Am 04.10.2018 20:05 schrieb Christer Holmberg <christer.holmberg@ericsson.com>:
>
> Hi,
>
>
> In order to keep track of the suggested RFC modifications, I suggest that we create GitHub issues.
>
>
> As an example, I created one for Shinji's suggestion to allow a proxy to increase the Min-SE header field value.
>
>
> https://github.com/cdh4u/draft-sessiontimer-race/issues/1
>
> [https://avatars0.githubusercontent.com/u/9333380?s=400&v=4]<https://github.com/cdh4u/draft-sessiontimer-race/issues/1>
>
> Proxy allowed to increase Min-SE header field value · Issue #1 · cdh4u/draft-sessiontimer-race<https://github.com/cdh4u/draft-sessiontimer-race/issues/1>
> github.com
> BACKGROUND: Section 8.1 of RFC 4028 says: "A proxy MUST NOT insert a Min-SE header field or modify the value of an existing header field in a proxied request if that request contains a Support...
>
>
>
>
>
> (As always, any formal decision whether to modify something will be made on the list)
>
>
> Regards,
>
>
> Christer
>
>
>
>
> ________________________________
> From: sipcore <sipcore-bounces@ietf.org> on behalf of Christer Holmberg <christer.holmberg@ericsson.com>
> Sent: Thursday, October 4, 2018 2:43 PM
> To: Roman Shpount
> Cc: OKUMURA Shinji; SIPCORE
> Subject: Re: [sipcore] Session-timer: Result below an acceptable value
>
>
> Hi,
>
>
> Sorry, I read your first e-mail wrong: I thought you said that the proxy would DECREASE Min-SE. But, now I see that you talk about INCREASE 😊
>
>
> I see no reason why a proxy couldn't increase Min-SE.
>
>
> As we have learned, the main users of session timer are proxies, not UAs, so a UA should not care if the minimum value is increased.
>
>> Technically speaking UA still care about how often they need to generate refresh since this can result in extra load on the UA.
> Sure, but increasing the Min-SE value will not result in extra load - on the contrary it may reduce load :)
>
>> When session timer is negotiated, S-E specifies the max acceptable value and Min-SE specifies min acceptable value, so proxy should be able to increase Min-SE and decrease SE.
> Correct.
>
> Regards,
>
> Christer
>
>
>