Re: [core] draft-tschofenig-core-coap-tcp-tls-03 : TCP Session Establishment

Carsten Bormann <cabo@tzi.org> Thu, 23 April 2015 06:56 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A41361B2C58 for <core@ietfa.amsl.com>; Wed, 22 Apr 2015 23:56:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.55
X-Spam-Level:
X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] 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 liCZPcOA08FF for <core@ietfa.amsl.com>; Wed, 22 Apr 2015 23:56:07 -0700 (PDT)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE7B91A8824 for <core@ietf.org>; Wed, 22 Apr 2015 23:55:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t3N6thlY004907; Thu, 23 Apr 2015 08:55:43 +0200 (CEST)
Received: from alma.local (ipbcc2e78c.dynamic.kabel-deutschland.de [188.194.231.140]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3lXTt56c4Zz2tSd; Thu, 23 Apr 2015 08:55:41 +0200 (CEST)
Message-ID: <5538976A.6020906@tzi.org>
Date: Thu, 23 Apr 2015 08:55:38 +0200
From: Carsten Bormann <cabo@tzi.org>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: weigengyu <weigengyu@bupt.edu.cn>
References: <9966516C6EB5FC4381E05BF80AA55F77B225BB90@US70UWXCHMBA05.zam.alcatel-lucent.com> <etPan.55317232.63a14e26.2525@alma.local> <9966516C6EB5FC4381E05BF80AA55F77B225BC27@US70UWXCHMBA05.zam.alcatel-lucent.com> <etPan.55317984.3602c202.2525@alma.local> <9966516C6EB5FC4381E05BF80AA55F77B225BC62@US70UWXCHMBA05.zam.alcatel-lucent.com> <FA343DFB62C6491DA5E82CCEA1574482@WeiGengyuPC> <9966516C6EB5FC4381E05BF80AA55F77B225F52B@US70UWXCHMBA05.zam.alcatel-lucent.com> <D90B31376C984E6F9DD11BF9DEAFE84A@WeiGengyuPC> <FC09CEBD05554E119046D876D7B55614@WeiGengyuPC>
In-Reply-To: <FC09CEBD05554E119046D876D7B55614@WeiGengyuPC>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/core/ubH7tQMldFP1JvLpUOKOThbf-lY>
Cc: "Carey, Timothy (Timothy)" <timothy.carey@alcatel-lucent.com>, core@ietf.org
Subject: Re: [core] draft-tschofenig-core-coap-tcp-tls-03 : TCP Session Establishment
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Apr 2015 06:56:08 -0000

weigengyu wrote:
> But what the application depends on to make the decision?
> From the viewpoint of network, it should be MTU.
> The MTU limits the size of UDP and CoAP message.

(Talking about the UDP case:)
That is indeed an area where the current IPv6 architecture doesn't
provide as much help as one would like it to.  The MTU is not
necessarily a good choice, in particular when hops with adaptation layer
fragmentation are involved.

The problem is mitigated a bit by the fact that usually a constrained
network with a preference for small packets is the last (incoming) or
first (outgoing) hop to a constrained node, so this node may have more
insight into good packet size choices than the network as a whole is
able to provide.  Using -block, this node can then communicate its
choice to a peer.

A while ago, I have proposed a way to get more (and more detailed)
information out of the network:
https://tools.ietf.org/html/draft-bormann-intarea-alfi-04
Earlier drafts of that had the problem that IPv6 hop-by-hop options tend
not to traverse the general Internet intact.  So I came up with a
SPUD-like alternative solution in -04 (see its section 5:
https://tools.ietf.org/html/draft-bormann-intarea-alfi-04#section-5
).  With (the real) SPUD now being looked at for communication to
middleboxes in general, that basic approach might actually go forward later.

Grüße, Carsten