Re: [Int-area] Comments on draft-ietf-intarea-frag-fragile-06

Stewart Bryant <stewart.bryant@gmail.com> Wed, 30 January 2019 18:42 UTC

Return-Path: <stewart.bryant@gmail.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 526DD130EA2 for <int-area@ietfa.amsl.com>; Wed, 30 Jan 2019 10:42:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Level:
X-Spam-Status: No, score=-1.988 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham 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 8Da3JJ0I7bDl for <int-area@ietfa.amsl.com>; Wed, 30 Jan 2019 10:42:36 -0800 (PST)
Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 22E3C130E6E for <int-area@ietf.org>; Wed, 30 Jan 2019 10:42:36 -0800 (PST)
Received: by mail-wm1-x334.google.com with SMTP id d15so22394wmb.3 for <int-area@ietf.org>; Wed, 30 Jan 2019 10:42:36 -0800 (PST)
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=xQJVuZMbOFwO56dXL4yD7BEN/0m6NXVVhxpDSFx6PMU=; b=aJOwekVgjB7gyFBg463mpnGlfXUFgY/R8PNS1Y5Q/98ftIjAPPnq9DVQMqm7OuXZdb omzGkGDF7tDCf5VEouaEvaWtjihkbQJlb25H2O4d6xi7Bj0/MLI4h5AZ+b7SvbwNwqKY y4rzKzZw1wIPZEd1ZxSXRn0+AmCe7Ob8BGwtYinsQM2b7XfHVjP5wg+gktIrX9hIYbuO N2zCYZ/N/kW/rP+Z2uashOJXtiEkoBa7Tnf4YJSD+I1kb8ZiUxCaJSHb/6ybO7TStzS1 e7eS6IwGyw1eNJh6DuLUK4msu0lKDoAuC7MBBxU19Mbf/BMhnJe/CN7EtELWQPnVqozg w1uQ==
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=xQJVuZMbOFwO56dXL4yD7BEN/0m6NXVVhxpDSFx6PMU=; b=d9v9sh2dHcVAlf1iW4254lJ0KYLEmA1zDJ/neT76z8QvOYOB85mdbc6R7OC/QYZ2DN CEueLG97K++Dt0KUGGaULp+Y151o0ZnT1QOa2DCdAShmVd7NcdYiVgRzQqnNbxX/Rmng HU/bWtLG2SRB8Gls5IL3HBMAUYlVt/aVEGouBYZNfohYSaVY+sJglIBdLzmstuVTpQMn j3PG4IT4XHWf6HuVy8hnIYifoc6UpwZ1OBIplsIkwZEDDySpV8LvN56s6J9YXa4xz0RU z0nKa7b+a3KvjoJmvwRlVDthNpXI3ajL3vhbtkXHAkIH9XUPVVbrmKj5Pg8IuNCxSZiU rdaQ==
X-Gm-Message-State: AJcUukfTmxUgzV+6jEE24FGy1VU+L9TH+Yt2iXMuguyd0lftywKwglvj iA/A3Y7uXtHiuiQqgNUZAJ5m/dSh
X-Google-Smtp-Source: ALg8bN4MRVCLmB9e8VyoT5b7tfxwIsnJCxSwqWwJc9Xpx+ffRJ7C6GJ/cyDxZWxJ/iXeYPxLQcjreg==
X-Received: by 2002:a1c:9855:: with SMTP id a82mr25069303wme.20.1548873754291; Wed, 30 Jan 2019 10:42:34 -0800 (PST)
Received: from [192.168.2.198] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id y145sm2838183wmd.30.2019.01.30.10.42.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Jan 2019 10:42:33 -0800 (PST)
To: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>, Fred Baker <fredbaker.ietf@gmail.com>, Tom Herbert <tom@herbertland.com>
Cc: int-area <int-area@ietf.org>
References: <CALx6S35kwvHL5iE4Ci10LQbPzun3k1C-T4m5B55yAyL+nP4sdQ@mail.gmail.com> <3B29EAA5-5989-4A8F-857B-3DEF63A7FEA7@gmail.com> <538a3580-dd3a-a778-dda0-bfc30f749bd9@gmail.com> <751bf1d2e6f94e98a5f9bafad3b27bf4@boeing.com> <a3136fb8-2c5b-5c53-bde1-f29cd55641e2@gmail.com> <6adb543c1bb447f5931450d74484027b@boeing.com> <40859995-4cc6-9758-f1b4-2a2404768f30@gmail.com> <c578dcf90f09482e9ca8ba190aeffd7a@boeing.com>
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-ID: <9565bc68-5004-d633-31b1-025521d83c1b@gmail.com>
Date: Wed, 30 Jan 2019 18:42:32 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <c578dcf90f09482e9ca8ba190aeffd7a@boeing.com>
Content-Type: multipart/alternative; boundary="------------1ACEFFC38BC2D852B39A5C2F"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/TRhtGPZJjaQ6KKBXNDpSfutHRLc>
Subject: Re: [Int-area] Comments on draft-ietf-intarea-frag-fragile-06
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Jan 2019 18:42:40 -0000

Because everyone already knows how to receive basic UDP and everyone 
already knows how to reassemble ordinary IP packets.

Along the path this is just ordinary UDP which everyone knows how to handle.

There is almost nothing to specify.

- Stewart


On 30/01/2019 18:38, Templin (US), Fred L wrote:
>
> Right, but when considering bringing an encapsulation protocol on 
> board, why not
>
> bring in a mature one like GUE and use either GUE fragmentation or Joe 
> Touch’s
>
> UDP trailer idea?
>
> Fred
>
> *From:*Stewart Bryant [mailto:stewart.bryant@gmail.com]
> *Sent:* Wednesday, January 30, 2019 10:35 AM
> *To:* Templin (US), Fred L <Fred.L.Templin@boeing.com>om>; Fred Baker 
> <fredbaker.ietf@gmail.com>om>; Tom Herbert <tom@herbertland.com>
> *Cc:* int-area <int-area@ietf.org>
> *Subject:* Re: [Int-area] Comments on draft-ietf-intarea-frag-fragile-06
>
> I think pretty much anything would need that wouldn't it?
>
> - Stewart
>
> On 30/01/2019 18:29, Templin (US), Fred L wrote:
>
>     Hi Stewart,
>
>     Sounds like that would require some sort of encapsulation protocol and
>
>     low-level code in the kernel or hardware to strip the UDP headers,
>     right?
>
>     Fred
>
>     *From:*Stewart Bryant [mailto:stewart.bryant@gmail.com]
>     *Sent:* Wednesday, January 30, 2019 10:15 AM
>     *To:* Templin (US), Fred L <Fred.L.Templin@boeing.com>
>     <mailto:Fred.L.Templin@boeing.com>; Fred Baker
>     <fredbaker.ietf@gmail.com> <mailto:fredbaker.ietf@gmail.com>; Tom
>     Herbert <tom@herbertland.com> <mailto:tom@herbertland.com>
>     *Cc:* int-area <int-area@ietf.org> <mailto:int-area@ietf.org>
>     *Subject:* Re: [Int-area] Comments on
>     draft-ietf-intarea-frag-fragile-06
>
>     Hi Fred
>
>     I had something quite simple in mind:
>
>     Fragment the IP packet just as you do today and send each fragment
>     as opaque data in a simple 8 byte basic UDP payload with port set
>     to IP. Set the source port based on a hash of the 5 tuple. Then
>     resemble the IP just like you always would.
>
>     - Stewart
>
>     On 30/01/2019 16:55, Templin (US), Fred L wrote:
>
>         Hi Stewart,
>
>         >> It we really need to fragment a packet, it would be better to
>         stick the fragments inside a common UDP/IP(no frag) shim.
>
>         I agree. Two different approaches for UDP fragmentation that
>         avoid IP fragmentation
>
>         are currently under consideration:
>
>         https://datatracker.ietf.org/doc/draft-ietf-intarea-gue-extensions/
>
>         https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/
>
>         Thanks - Fred
>
>         *From:*Int-area [mailto:int-area-bounces@ietf.org] *On Behalf
>         Of *Stewart Bryant
>         *Sent:* Wednesday, January 30, 2019 6:14 AM
>         *To:* Fred Baker <fredbaker.ietf@gmail.com>
>         <mailto:fredbaker.ietf@gmail.com>; Tom Herbert
>         <tom@herbertland.com> <mailto:tom@herbertland.com>
>         *Cc:* int-area <int-area@ietf.org> <mailto:int-area@ietf.org>
>         *Subject:* Re: [Int-area] Comments on
>         draft-ietf-intarea-frag-fragile-06
>
>         On 29/01/2019 23:37, Fred Baker wrote:
>
>
>
>
>
>                 Section 4.5:
>
>                 "IP fragmentation causes problems for some routers that support Equal
>
>                 Cost Multipath (ECMP). Many routers that support ECMP execute the
>
>                 algorithm described in Section 4.4 in order to perform flow based
>
>                 forwarding;
>
>               
>
>             As far as I know, routers that hash fields in the IP header to select a en ECMP next hop do so because all packets in a flow will hash the same way (modulo the issues with the transport port number), not because they are doing per-flow forwarding. The do so explicitly to avoid having to maintain per-flow state and yet make all fragments of a message follow the same path.
>
>         I agree with Fred. ECMP is normally done to distribute the
>         load over the available next hops on a best effort basis.
>         Originally it was done per packet, but that gave problems with
>         out of order packet delivery, so the routers moved to doing it
>         based on the five tuple described in this draft. It is a
>         stateless best effort ECMP process with no regard to specific
>         flows and the path for any five tuple may move arbitrarily if
>         routing changes its mind on the ECMP set.
>
>         Fragmented packets are really bad news in networks that need
>         ECMP. There is not enough entropy in the SA/DA/Protocol
>         triplet and anything else results in misorder. But if ECMP is
>         not done this overloads the default path.
>
>         MPLS is also stateless but there are more options, although
>         the most common is to look past BoS to the five tuple, however
>         some "features" make mistakes and look at a non-existent five
>         tuple despite hints in the packet that thus is a bad idea.
>
>               
>
>                 therefore, the exhibit they same problematic behaviors
>
>                 described in Section 4.4. In IPv6, the flow label may alternatively
>
>                 used as input to the algorithm as opposed to parsing the transport
>
>                 layer of packets to discern port numbers. The flow label should be
>
>                 consistently set for a packets of flow including fragments, such that
>
>                 a device does not need to parse packets beyond the IP header for the
>
>                 purposes of ECMP."
>
>                   
>
>                 Add to section 7.3:
>
>                   
>
>                 "Routers SHOULD use IPv6 flow label for ECMP routing as described in [RFC6438]."
>
>         If we want to migrate to the FL then we really need to state
>         that the FL MUST be set by the sender. Without, that we are
>         never going to wean routers off looking at the five tuple, if
>         indeed we ever succeed in doing that.
>
>         It we really need to fragment a packet, it would be better to
>         stick the fragments inside a common UDP/IP(no frag) shim. Then
>         the forwarders could carry on just as they are. We would never
>         get misorder and we would not be faced with the impossible
>         problem of changing the Internet core forwarding behaviour to
>         a single consistent model.
>
>         - Stewart
>
>                   
>
>                   
>
>                 _______________________________________________
>
>                 Int-area mailing list
>
>                 Int-area@ietf.org  <mailto:Int-area@ietf.org>
>
>                 https://www.ietf.org/mailman/listinfo/int-area
>
>               
>
>             --------------------------------------------------------------------------------
>
>             Victorious warriors win first and then go to war,
>
>             Defeated warriors go to war first and then seek to win.
>
>                   Sun Tzu
>
>               
>
>
>
>
>
>             _______________________________________________
>
>             Int-area mailing list
>
>             Int-area@ietf.org  <mailto:Int-area@ietf.org>
>
>             https://www.ietf.org/mailman/listinfo/int-area
>