Re: [Lwip] Last Call: <draft-ietf-lwig-tcp-constrained-node-networks-10.txt> (TCP Usage Guidance in the Internet of Things (IoT)) to Informational RFC

Michael Richardson <mcr+ietf@sandelman.ca> Sat, 19 September 2020 21:50 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: lwip@ietfa.amsl.com
Delivered-To: lwip@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 140753A0AE0; Sat, 19 Sep 2020 14:50:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 gZYGRue1oAtA; Sat, 19 Sep 2020 14:50:10 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FE9C3A0ADA; Sat, 19 Sep 2020 14:50:08 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id D3CEA389C5; Sat, 19 Sep 2020 17:28:44 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Cg1s_6YLYEBk; Sat, 19 Sep 2020 17:28:41 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 4AD69389C4; Sat, 19 Sep 2020 17:28:41 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 1584372; Sat, 19 Sep 2020 17:49:49 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Ted Lemon <mellon@fugue.com>, Carles Gomez Montenegro <carlesgo@entel.upc.edu>, draft-ietf-lwig-tcp-constrained-node-networks@ietf.org, last-call@ietf.org, lwig-chairs@ietf.org, lwip@ietf.org
In-Reply-To: <8BDF59D7-8451-46DA-A0AD-2AA1EDB59943@fugue.com>
References: <160026450341.4741.15386274889650653489@ietfa.amsl.com> <157F51F5-28D9-46BE-A408-D79D647AE495@fugue.com> <A4BB6B20-87EA-4F54-B35F-89FD7CBF9C80@fugue.com> <a7d33f0bd4f5491be1affd868fb7144b.squirrel@webmail.entel.upc.edu> <8BDF59D7-8451-46DA-A0AD-2AA1EDB59943@fugue.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Sat, 19 Sep 2020 17:49:49 -0400
Message-ID: <11453.1600552189@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/lwip/tfDa4RwpT_xjgl_ewWmvQE7rjY0>
Subject: Re: [Lwip] Last Call: <draft-ietf-lwig-tcp-constrained-node-networks-10.txt> (TCP Usage Guidance in the Internet of Things (IoT)) to Informational RFC
X-BeenThere: lwip@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Lightweight IP stack. Official mailing list for IETF LWIG Working Group." <lwip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lwip>, <mailto:lwip-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lwip/>
List-Post: <mailto:lwip@ietf.org>
List-Help: <mailto:lwip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lwip>, <mailto:lwip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 19 Sep 2020 21:50:13 -0000

Ted Lemon <mellon@fugue.com> wrote:
    > The reason I’m concerned about this is that it’s my understanding that
    > generally on LLNs fragments are acknowledged at the packet level, not
    > at the fragment level. This means that if five fragments are
    > transmitted and one dropped, all five have to be retransmitted. This
    > assumption may actually not be true—I haven’t tested it. It’s based on
    > what others have told me about how this works. If this assumption isn’t
    > true, then my primary concern goes away. The concern I have is that as
    > packet loss rates rise, the likelihood of any given IP packet making it
    > across an 802.15.4 mesh intact (with no fragments lost) drops. Because
    > every fragment has to be retransmitted, this can result in a lot of
    > extra traffic being sent, which can further increase packet loss.

There is always a terminology issue, because things got overloaded in my opinion.
RFC4944 was never clear enough for my liking, and overloads "fragment"

So let me be clear:
   frame: a thing transmitted at layer 2
   fragment: a part of an IP packet that has undergone fragmentation
   fraglet:  a sometimes used term for "fragmentation" at layer 2.
   segment: a part of a TCP transmission that can be ACKnowledged
   packet: a IP packet as we know it.

LLNs usually take packets which are 1280 or less and turn them into fraglets
("fragments") for transmission through the LLN.  Many LLN technologies
including 802.15.4 provide to ACKs for each transmission, and there is a
retransmission a few times, but then it stops and goes on.  Does this result
in an immediate loss of the entire packet?  Yes, often.

RFC4944 says that each node re-assembles the fraglets to a packet at each
hop, and then tries again.  But, we have proposals for fraglet forwarding.

IP can, of course, fragment a packet into many IP fragments, each of which
can be transmitted on their own, to be assembled by the end points, not the
intermediate nodes.

TCP works best if you never create IP fragments, so setting the segment size
to what can efficiently get through the LLN is good.

I'm sorry to repeat, but I think we've done ourselves a disservice by not
being more precise.

    > So if that’s true, it makes sense to keep the mss short, preferably
    > shorter than 1280. 1280 would be thirteen fragments on 802.15.4, if my
    > math is right. I think ideally we’d want to keep the MSS down nearer to
    > 500 bytes.

It sounds right that an *MSS* of 1280 would be 13 fraglets on 802.15.4.
I think that if you set the MTU to 1280, you get an MSS smaller than 1280 though.

     > It may be that my reasoning is completely wrong here, but the reason
     > for my reaction to this document is that this is my present
     > understanding of the problem, and hence the recommendation of a 1280
     > byte mss seems wrong. If I misread that, I apologize. As I said, I
     > need to give the document a closer read.  Generally speaking I would
     > really like to see the old canard that TCP can’t work on LLNs put to
     > pasture, so I want this work to succeed. Again, I’m sorry for the
     > unkind comment.

The fraglet forwarding proposal would more reliably forward larger IP
packets, so a larger MSS might actually be more efficient use of energy.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide