Re: [tsvwg] Fwd: New Version Notification for draft-herbert-udp-space-hdr-00.txt

Tom Herbert <tom@herbertland.com> Tue, 12 March 2019 20:01 UTC

Return-Path: <tom@herbertland.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70E5E131150 for <tsvwg@ietfa.amsl.com>; Tue, 12 Mar 2019 13:01:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 FUBIClZSf2Jn for <tsvwg@ietfa.amsl.com>; Tue, 12 Mar 2019 13:01:38 -0700 (PDT)
Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 CE369131109 for <tsvwg@ietf.org>; Tue, 12 Mar 2019 13:01:37 -0700 (PDT)
Received: by mail-qt1-x82f.google.com with SMTP id z39so4125601qtz.0 for <tsvwg@ietf.org>; Tue, 12 Mar 2019 13:01:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lDH2MH709POAW3PHuP/YcwN6Hy2QeY2hSKZFSLA5SB8=; b=K+2Jtj6lrUE4B7kzwduHrxxABARqtp0oVzXyQA/6rCgY6ixHTmCySspn5qt/n7b2dQ EMg5R0nlZ5z0UzL4g1LkN+Y2nlkT70tISVS8sFMSDxvMV4cVuDQnORkSlBGCapl82HUB HVf/vRG51hNDs3mce+gXeJyHrH4RWlh8mk3sKm7/jV8ddBUwyN159RIQdYyQZ7c6VRO0 N2sV3LycDtj1GRk0XMR4O/wLSIF2xxFcoqrJ0IIAvtOk/ZoI+Dkh7wKF5DzmyNbnfm9S dOKFuGvoiZkPYnzIQBJ9EDOLQuvAvIQy+qdLUU2RTnNgexIQzsleplmaLK2LCwRZRvGw rrvw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lDH2MH709POAW3PHuP/YcwN6Hy2QeY2hSKZFSLA5SB8=; b=X7T/TuzpaZa3PFlc89jvIQRDv+fsSoq8GSVkbB+oWR1Y1FZTqbTMfDxKaMA2agjmhV 7GR17XDaJwBC/U4MblLtu1EkPCRgyK6FOOo+G0fH/oXNibDMyPGSjy3uBPVUbEXXDZz4 cmjn6MYdI6aPJp3B1OGu+K2cXjMxhWvwEf5aF1vjeiALBpGMNSDxw7vdIePAE0rCGjfB zRxU7Es/EQoc/ot37qZN7AkK7x9goRfr7pHr1sR+em/ClRtOnpFfVdmuyXCN++lrETry B3Z1zxobzLc+VHNZgk7OSm7GeSY1+tTTx+mItiJIC+VzGdkLudpsxsE/Q+CPzH4YR9+c mq9Q==
X-Gm-Message-State: APjAAAXwHdiO/Pd59WiiTAcxf0X4ZBlrQBpMwkrrd+1QmmiLAFvOFO8H uRJ2HUY1dzGm3LV8oJklF1qFNjSVSOug+50dxF9u6IOJ
X-Google-Smtp-Source: APXvYqyEepqCDlpRRuAV4rs7NCq6SjOD6uWjScSByYB0kRoe0fccoJMXvWNgOtW4/hmoWJ7t3LJPAlhzRCs3wSgv+N4=
X-Received: by 2002:a0c:9681:: with SMTP id a1mr32167037qvd.72.1552420896874; Tue, 12 Mar 2019 13:01:36 -0700 (PDT)
MIME-Version: 1.0
References: <CACL_3VF8M5TdGhxD-r77s+g1wRb8KFHA18tJK-rvXJWfE8Z3oQ@mail.gmail.com> <CALx6S341bSCRt0vppT-vhEHEd_NBTh78rUwBWa2TOba4tsXquw@mail.gmail.com> <CACL_3VHFUVSvs23JPLErYFbLBftM_Ehi0Mssymw_jmeUbmT6MA@mail.gmail.com>
In-Reply-To: <CACL_3VHFUVSvs23JPLErYFbLBftM_Ehi0Mssymw_jmeUbmT6MA@mail.gmail.com>
From: Tom Herbert <tom@herbertland.com>
Date: Tue, 12 Mar 2019 13:01:27 -0700
Message-ID: <CALx6S35zzgwvcyXBb-mhXk2hy1JreWpokUUq=T=9oqbosfwPrg@mail.gmail.com>
To: "C. M. Heard" <heard@pobox.com>
Cc: tsvwg <tsvwg@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/6KzIOD43Wu1oFiJC-aWQsDMUaEU>
Subject: Re: [tsvwg] Fwd: New Version Notification for draft-herbert-udp-space-hdr-00.txt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Mar 2019 20:01:40 -0000

On Tue, Mar 12, 2019 at 12:22 PM C. M. Heard <heard@pobox.com> wrote:
>
> On Tue, Mar 12, 2019 at 7:23 AM Tom Herbert <tom@herbertland.com> wrote:
> > I see. The same effect can by had by using a two byte pseudo header in
> > the checksum that contains the difference between the IP length and
> > the UDP length.
>
> Yes. My sense from reading the draft is that the optimum approach would
> be to incorporate this pseudo-header compensation for ***each*** section
> separately. Basically, the total length for a section (including header
> and pad bytes) would be included in the checksum. The pad bytes can be
> ignored since they are required to be zero. This assumes that every
> surplus octet is included in some section.
>
Mike,

Actually, only the first surplus section needs the pseudo header
adjustment. Any other sectiosn sum to zero so that the net sum of the
payload section is the length difference. I'm not sure what "surplus
octet " means.

> > So for the "cost" of a mandatory two byte checksum, we get:
> >
> > - Detection of non-standard uses of the surplus space
> > - Detection of corrupted bits in the option space
> > - Middleboxes can calculate UDP checksum based on IP length with no
> > additional bits needed for adjustment value
> > - Detection that the IP length is corrupted or changed inflight
> > - Uniformity and reuse of checksum APIs in implementation with other
> > IP protocols that contain a checksum (IP, TCP, UDP, GRE)
> > - Compatibility with NIC checksum offload
>
> Sounds correct to me. One cost: the LITE option is of no use under this
> proposal, since the LITE data would be checksummed. That defeats the
> purpose of LITE.
>
To handle that a surplus area could be defined for containg UDP
payload. The Type Specific data contains the UDP payload followed by
the four byte swapped value. To restore the UDP payload the swap needs
to be done and the UDP length needs
to be set-- UDP lengths aren't necessarily a multiple of four so to
handle that four different types can be defined.

An advantage of this method is that teh UDP payload is still covered
by a per packet checksum and is offloadable. This obviates the need
for a reassembly checksum (very expensive to compute).

Tom

> Mike Heard