Re: [tsvwg] Status of ECN encapsulation drafts (i.e., stuck)

"Rodney W. Grimes" <> Sat, 14 March 2020 22:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EAFF63A0F17 for <>; Sat, 14 Mar 2020 15:18:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.623
X-Spam-Status: No, score=-1.623 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.274, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qLVilpCUZePd for <>; Sat, 14 Mar 2020 15:18:26 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5ECBA3A0F16 for <>; Sat, 14 Mar 2020 15:18:26 -0700 (PDT)
Received: from (localhost []) by (8.13.3/8.13.3) with ESMTP id 02EMIJf9085997; Sat, 14 Mar 2020 15:18:19 -0700 (PDT) (envelope-from
Received: (from ietf@localhost) by (8.13.3/8.13.3/Submit) id 02EMIJ9D085996; Sat, 14 Mar 2020 15:18:19 -0700 (PDT) (envelope-from ietf)
From: "Rodney W. Grimes" <>
Message-Id: <>
In-Reply-To: <>
To: Bob Briscoe <>
Date: Sat, 14 Mar 2020 15:18:19 -0700
CC: Sebastian Moeller <>, "" <>
X-Mailer: ELM [version 2.4ME+ PL121h (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Archived-At: <>
Subject: Re: [tsvwg] Status of ECN encapsulation drafts (i.e., stuck)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 14 Mar 2020 22:18:28 -0000

	Questions and comments in line.


> Sebastian,
> On 13/03/2020 22:54, Sebastian Moeller wrote:
> > Dear All,
> >
> > so in this example we need an operator that operates a tunnel (encapsulation and decapsulation) and an AQM on the same tunnel and is considered to both (mis-)configure the tunnel to allow fragmentation and operate an SCE-AQM on hops along the tunnel's path.
> Tunnels are often constructed over the top of the network operator that 
> runs the physical equipment (incl. any AQM). Overlays are one of the 
> common motivations for tunnelling.
> > Is that really considered to be a sensible deployment that is worth catering to? I would guess having a tunnel that fragments/defragments alone would be painful/sub-optimal. Why would an operator that consciously accepted such a tunnel design (as there probably real world constraints that can justify such an arrangement) would then go and add a non-tunnel compatible AQM? Are fragmenting tunnels really such a big part of the commercial ISP world?t
> Short answer: I don't know.
> Where an operator who sets up a tunnel can control the MTU of the links, 
> I would imagine fragmentation is highly unlikely. But for overlays using 
> tunnelling, most tunnel endpoints use PMTUD between themselves to find a 
> good tunnel MTU, and I would imagine they use fragmentation for IPv4 
> (because they have to, if their "packet too big" ICMPs are being 
> blocked) for any incoming packets that don't fit once they add tunnel 
> headers. But I don't know how often they actually have to fragment 
> (depends on end-systems strategies are to keep the MTU below this point).

My experience both personally and with helping others to
configure tunnels is that if PMTU is not setup correctly
the tunnels fail to carry packets >PMTU.  I only know
of one tunnel transport that has working fragmentation
and reassembly, but my exposure set is rather small.

> The only concrete data I can find is from the year 2000.
> In this case all the packets on the link were fragments, and "A 
> significant portion of the fragmented traffic ... is tunneled traffic." 
> I don't know whether this link was chosen for this study because all the 
> packets were fragments, or whether it would have been easy to find other 
> links with a high proportion of fragments.
> Finding the best max packet size is an area where neither IPv4 nor IPv6 
> has ever found a good solution. Getting a tunnel to fragment and 
> reassemble is indeed painfully sub-optimal, but all the other solutions 
> have their own problems. It is possible the sub-optimality is often 
> going on under-the-covers, just because it works. I do know that, for 
> IPv4, the Don't Fragment (DF) flag is often ignored by tunnels, as a 
> preferable alternative to just ditching the traffic.

What do you base your "know" on?
Can you please site an implementaiton?

> In the absence of the IP layer solving this problem, Gorry's group found 
> that about 20% of end-systems are just clamping the IPv4 TCP max segment 
> size lower than necessary. And for IPv6 most are just using the min 
> segment size. See:
> Again only for TCP, middleboxes can edit the MSS advertised in each 
> packet to fool the hosts into using a smaller max segment size. You can 
> configure a Cisco box (and I'm sure others) to do this when you're using 
> it for tunnelling. The above study from Gorry's group didn't find much 
> evidence of this though.
> PLPMTUD solves this problem end-to-end (see [RFC4821] for TCP etc. and 
> [draft-ietf-tsvwg-datagram-plpmtud] not yet published for UDP). However, 
> where a tunnel already solves the problem (sub-optimally) for IPv4 using 
> fragmentation, I can't imagine that anyone would disable it, because it 
> is still necessary and it still works.
> Further reading.
> I just compiled a list, then realized everything is already cited here, 
> in the context of minimizing latency:
> You could also try 
> ..
> Bob
> >
> > Best Regards
> > 	Sebastian
> >
> >
> >
> >
> >> On Mar 13, 2020, at 19:50, Bob Briscoe<>  wrote:
> >>
> >> Jonathan,
> >>
> >> On 13/03/2020 18:15, Jonathan Morton wrote:
> >>>> On 13 Mar, 2020, at 7:58 pm, Bob Briscoe<>  wrote:
> >>>>
> >>>> Are you reading my recent emails, or the main email?
> >>> The recent ones, because I'm trying to establish this fundamental point first.  Until I can figure out what you *do* mean by CE marks being doubled, there's no point in discussing anything more subtle.
> >>>
> >>> So again, I ask: what context am I missing?
> >> I said "No." I.e. the AQM is not marking before the tunnel ingress. It is marking between tunnel ingress and egress.
> >>
> >> How can I know what context you're missing if you haven't read the email? Presumably that means you're missing all the context given in the email.
> >>
> >> Pls can you take these sort of emails off the IETF lists - I'm sure no-one cares for this sort of content-free conversation.
> >>
> >>
> >> Bob
> >>>   - Jonathan Morton
> >> -- 
> >> ________________________________________________________________
> >> Bob Briscoe
> >>
> -- 
> ________________________________________________________________
> Bob Briscoe

Rod Grimes