[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.