Re: [tsvwg] draft-ietf-tsvwg-rfc6040update-shim:SuggestedFragmentation/Reassemblytext

Jonathan Morton <chromatix99@gmail.com> Sun, 21 March 2021 18:42 UTC

Return-Path: <chromatix99@gmail.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 9B4F33A12E6; Sun, 21 Mar 2021 11:42:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.052
X-Spam-Level:
X-Spam-Status: No, score=0.052 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 b9BSvpolpC3I; Sun, 21 Mar 2021 11:42:23 -0700 (PDT)
Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 1FBB73A12E5; Sun, 21 Mar 2021 11:42:23 -0700 (PDT)
Received: by mail-lf1-x134.google.com with SMTP id x28so17849176lfu.6; Sun, 21 Mar 2021 11:42:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vD5sF3edG2Ki4514LmjpNQdqMjTxXVJq0dO+yYvDivQ=; b=mc+nWS1gYp5jcyN9jYCyaV+CjrXvFdE9iEXP9QLc2Tvd5ekjT9HqzngJP893MbTrkQ A7y2wKZFxDjeVHDql7v3PYgdLCJNF6gB2GmCkayPCXHsaDqnaX+BVaulDGks6CI3KlW1 dyKyVYEoDgx1Tsa5OF6mepvKH2pZ0tdZSKJNotuuypsRI4bHgC+S972vf/zO12l2fHYE jFZ8xbncrUmCiqUPzMtY80h7OvLkXx1nj9R8qbYvWg8ROuioUwq04/SO/oIesXAxiGzC APRmsjtNt1/foLQO8LnKWYecICm8EitoFW2JBF3aIWguXsvw/w7D3Ve0q6yjGpfHVauU vVpA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vD5sF3edG2Ki4514LmjpNQdqMjTxXVJq0dO+yYvDivQ=; b=AwLDpp2HoyXNi+3k8DdReObphKUucFd863NqMIjbNPHLoIyZqZTasDZYSRLQzg8fdV FyT0uMBL6MiFI5EHBmEXt/9kD19oPXy364UNJpB5GX32wJv3vRa2EqmosLMnyhDciZKf 4vss+gHi2YSFZ3XS3G/pzWaD+R0+wH+qtCWA6ay4gCYxpVqjhnQeR7v5RDYwhLAVSiws 9PhQ10JjMobj9HUFDKqXIhT4t9FO+v8fnMyZIY0qyiWdsSCMFvIxNDkLhJTEabuTmxnq cp8u3DNpC5ZcYEF/LU20gBd86PMbQC8QBDWiNJLTLDxxhSDml5Rc0/opj12E8fPoe9Fq aFPQ==
X-Gm-Message-State: AOAM530YMkZ3kD94gP4hPMDSQ833W5xHW0gUrw6wwDNjpXkMIKyYiwK/ Icp6lLoff7WXAavGZ1Vgvrr3nuSEoDs=
X-Google-Smtp-Source: ABdhPJz4bDd3p3tFhZjPZdCVqmDM+Ee9yl8hcOcGRdd5Cab2fo5MbNxju+G5W8s9JYsDEioOw9H/bQ==
X-Received: by 2002:ac2:43a3:: with SMTP id t3mr6710688lfl.340.1616352136320; Sun, 21 Mar 2021 11:42:16 -0700 (PDT)
Received: from jonathartonsmbp.lan (178-55-25-11.bb.dnainternet.fi. [178.55.25.11]) by smtp.gmail.com with ESMTPSA id y4sm1302537lfj.254.2021.03.21.11.42.15 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 21 Mar 2021 11:42:15 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\))
From: Jonathan Morton <chromatix99@gmail.com>
In-Reply-To: <8ac0d6dd-1648-ee8d-d107-55ef7fe7695f@bobbriscoe.net>
Date: Sun, 21 Mar 2021 20:42:14 +0200
Cc: Markku Kojo <kojo@cs.helsinki.fi>, Joe Touch <touch@strayalpha.com>, Markku Kojo <kojo=40cs.helsinki.fi@dmarc.ietf.org>, "tsvwg-chairs@ietf.org" <tsvwg-chairs@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <CD5B98D1-9BAE-4B74-8751-A8AF293AEFC3@gmail.com>
References: <CE03DB3D7B45C245BCA0D243277949363076629A@MX307CL04.corp.emc.com> <CE03DB3D7B45C245BCA0D24327794936307662EA@MX307CL04.corp.emc.com> <1920ABCD-6029-4E37-9A18-CC4FEBBFA486@gmail.com> <CE03DB3D7B45C245BCA0D2432779493630768173@MX307CL04.corp.emc.com> <6D176D4A-C0A7-41BA-807A-5478D28A0301@strayalpha.com> <CE03DB3D7B45C245BCA0D24327794936307688C5@MX307CL04.corp.emc.com> <alpine.DEB.2.21.1911171041020.5835@hp8x-60.cs.helsinki.fi> <9024d91a-bb08-fb45-84f8-ce89ba90648d@bobbriscoe.net> <alpine.DEB.2.21.2012141735030.5844@hp8x-60.cs.helsinki.fi> <1e038b64-8276-3515-ac45-e0fc84e1c413@bobbriscoe.net> <alpine.DEB.2.21.2103081540280.3820@hp8x-60.cs.helsinki.fi> <3c778eb9-56dc-3d58-0de4-c6373d1090ec@bobbriscoe.net> <alpine.DEB.2.21.2103181233160.3820@hp8x-60.cs.helsinki.fi> <8ac0d6dd-1648-ee8d-d107-55ef7fe7695f@bobbriscoe.net>
To: Bob Briscoe <ietf@bobbriscoe.net>
X-Mailer: Apple Mail (2.3445.9.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/RGztXU2LFjcb3iL-fw8UaxG0lpk>
Subject: Re: [tsvwg] draft-ietf-tsvwg-rfc6040update-shim:SuggestedFragmentation/Reassemblytext
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: Sun, 21 Mar 2021 18:42:28 -0000

> On 20 Mar, 2021, at 8:27 pm, Bob Briscoe <ietf@bobbriscoe.net> wrote:
> 
> It's not enough to make ecn-encap the same as shim. The reassembly logic in RFC3168 is only defined when packets are reassembled from /smaller/ fragments. When a L2 frame is /larger/ than an IP packet, or /overlaps/ the boundary between IP packets, the reassembly logic in RFC3168 makes is undefined - it makes no sense. 
> 
> For instance, some link layers treat IP packets as a continuous byte stream, then break the stream into the largest possible frames, like so: 
> 
> ----------------->+<---------------------------->+<------------------------------>+<----
>         Fr1       |                Fr2           |             Fr3                |     
> +-------------+-------------+-------------+-------------+-------------+-------------+---
> |   Pkt1      |    Pkt2     |    Pkt3     |   Pkt4      |    Pkt5     |   Pkt6      |
> +-------------+-------------+-------------+-------------+-------------+-------------+---
> 
> Then, say Fr2 was marked. On decap should Pkt2, Pkt3 & Pkt4 be marked, or just Pkt3 & Pkt4?

I would say that one mark applied at link layer should result in one mark applied to one IP packet.  Exactly which one doesn't really matter, as long as it has some tangible connection to the frame that was marked.  Word it that way, and we'll be fine.  In particular, this method should work for *both* conventional and high-fidelity sensitive traffic.

 - Jonathan Morton