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

[Bob Briscoe <[e-mail]>]

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).

The only concrete data I can find is from the year 2000.
https://www.caida.org/research/traffic-analysis/fragments/
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.

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:
https://iain.learmonth.me/stuff/pubs/UsableMTU2018.pdf
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:
http://bobbriscoe.net/projects/latency/latency_preprint.pdf#subsubsection.3.1.5

You could also try 
https://labs.ripe.net/Members/gih/evaluating-ipv4-and-ipv6-packet-fragmentation 
.



Bob
>
> Best Regards
> 	Sebastian
>
>
>
>
>> On Mar 13, 2020, at 19:50, Bob Briscoe<[e-mail]>  wrote:
>>
>> Jonathan,
>>
>> On 13/03/2020 18:15, Jonathan Morton wrote:
>>>> On 13 Mar, 2020, at 7:58 pm, Bob Briscoe<[e-mail]>  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 Briscoehttp://bobbriscoe.net/
>>

-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/