[TLS] DTLS retransmit question
Manuel Pégourié-Gonnard <mpg@polarssl.org> Tue, 30 September 2014 22:58 UTC
Return-Path: <mpg@polarssl.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7DF01ACD03 for <tls@ietfa.amsl.com>; Tue, 30 Sep 2014 15:58:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.797
X-Spam-Level: *
X-Spam-Status: No, score=1.797 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
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 47Yx8xwXJ5lc for <tls@ietfa.amsl.com>; Tue, 30 Sep 2014 15:58:58 -0700 (PDT)
Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41C671ACC87 for <tls@ietf.org>; Tue, 30 Sep 2014 15:58:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:To:MIME-Version:From:Date:Message-ID; bh=6wB2/5WNkPwhkp3KdhbEXpqCdNU81bZ5xpwDuXXsKvM=; b=in70yztGwMb2loa+ySxWl8To7Dx9G5NzsoBIp16NL+JXWzWDghfNo7wtLsojyZsP0wdFV0VghkyDvOGvsdUrtMzfAFu1Rh6cmIxaX4N7sNz/01jmGmj6SHVx3308Y+QG14BkmJ6MYkoWWkXNjoVbfJFbusCwAbFqSqOrlcw5oQY=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <mpg@polarssl.org>) id 1XZ6NU-0003ha-DC for tls@ietf.org; Wed, 01 Oct 2014 00:58:41 +0200
Message-ID: <542B35A2.5090900@polarssl.org>
Date: Wed, 01 Oct 2014 00:58:42 +0200
From: Manuel Pégourié-Gonnard <mpg@polarssl.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
To: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/YDrACyCe6m4obBFpxXod-_O6KUo
Subject: [TLS] DTLS retransmit question
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Sep 2014 22:58:59 -0000
Hi all, I'm having trouble interpreting some text from RFC 6347 section 4.2.4: Although each flight of messages may consist of a number of messages, they should be viewed as monolithic for the purpose of timeout and retransmission. [...] There are three ways to exit the WAITING state: [...] 2. The implementation reads a retransmitted flight from the peer: the implementation transitions to the SENDING state, [...] Does that mean an implementation is supposed to transition from WAITING to SENDING only when it reads the retransmission of a whole flight? Since the underlying transport is not reliable, one of the messages of the retransmitted flight might get lost: should that prevent from retransmitting in return? An option would be to retransmit as soon as a retransmitted message from the last flight is seen, but that would result in one retransmission per received message in the flight retransmitted by the peer, which would result in a lot of probably useless retransmission, which is bad for congestion. Another option is to retransmit only when a retransmission of the last message of the previous flight is seen, which results in less retransmissions and is a bit less sensitive to message loss than checking for the whole flight. It's also easier to implement (especially for the flight containing the Finished message, since messages from previous epochs can then be dropped by the record layer). This is currently my preferred option, I think. Any clarification of the intention of the RFC, or sensible advice on what to do, would be appreciated. Thanks, Manuel.
- [TLS] DTLS retransmit question Manuel Pégourié-Gonnard