Re: [tsvwg] SCE and tunnels / encapsulations

[Dave Taht <[e-mail]>]

ya know? I think everybody should get some sleep.

certainly a patch needs to get prepared and queued up for
linux-stable, which, btw, I think for the first time in ages,
everybody here can agree on. That's a good feeling.

On Sun, Apr 26, 2020 at 11:03 PM Sebastian Moeller <[e-mail]> wrote:
>
> Hi Dave,
>
> Good point.
>
> But I can not help myself noting that all of this assumed that the heavily tunneled paths we are talking about will actually roll out a pist-rfc3168 AQM. I for one do not believe that the business case for doing that had changed one iota either by L4S or by SCE, so at least for initial roll-out I consider this to be a non-issue.
> I also add one level of confusion I spit in Bob's argument:
> In the tunneled traffic of day a complete end user link or of a VPN, how can you expect exclusively L4S traffic to be present? So I question that even if we had AQMs on tunneled paths that doing the 1/p congestion control feed back would be a safe thing to do. And leaking individual packet's ECT(1) out of a VPN is IMHO severe enough an isolation violation to stop using that VPN for good. But again, I really do not see the internet growing AQMs at the problematic places any time soon, and I assume even with ECT(1) as output we would have time to prepare not only safe but also high fidelity tunnel passage should this become a limiting step in the future.
>
>
> Best
> Sebastian
>
> On 27 April 2020 07:35:52 CEST, Dave Taht <[e-mail]> wrote:
>>
>> I learned something I didn't know btw. ping -Q "value" on linux, at
>> least - sets the same value on the receive as the send.
>> they took "echo" seriously way back then.
>>
>> and generating frags can be "interesting" when transiting a tunnel.
>> Abusing one of my wireguard tunnels
>> as a test:
>>
>> ping -s 1500 -f -Q 1 never.you.mind.ip
>> ping -s 1500 -f -Q 2 never.you.mind.ip
>>
>> shows that 2 can change to 3 by the aqm and be turned back into 3 at
>> the egress point (inner)
>> shows that 1 can change to 3 by the aqm and but *not* be turned back
>> into 3 at the egress point (inner), it stays at 1
>>
>> with what? 20%? 60%? of the world transiting tunnels? this is a major
>> deployment problem for both l4s and sce.
>>
>>
>>
>>
>>
>>
>>
>> On Sun, Apr 26, 2020 at 9:18 PM Dave Taht <[e-mail]> wrote:
>>>
>>>
>>>  thank you for taking a look.
>>>
>>>  It would be good to know what cisco and juniper actually do, by
>>>  spitting these bits into them
>>>  they are all available as vms now, cisco has 3 major linux versions in their
>>>  stacks so far as I recall, pretty ancient, and for all I know do some
>>>  tunnel types in hw.
>>>
>>>  openvpn and other userspace vpns would be good to look at also.
>>>
>>>  On Sun, Apr 26, 2020 at 8:17 PM Bob Briscoe <[e-mail]> wrote:
>>>>
>>>>
>>>>  Dave,
>>>>
>>>>  On 27/04/2020 01:33, Dave Taht wrote:
>>>>
>>>>  At one point I had done a thorough survey of all the open source
>>>>  network stacks in the world,
>>>>  and largely found they copied both bits back and forth. But I've lost
>>>>  my notes on this and do not
>>>>  remember clearly.
>>>>
>>>>
>>>>  Should copy ECN field to outer on encap, but shouldn't blindly copy them back from outer on decap.
>>>>  Forwarded ECN field should depend on combination of outer and inner (see table at github URL below).
>>>
>>>
>>>>  Earlier this evening, Olivier and I checked all the different tunnel code in Linux that we could find.
>>>>
>>>>  Most followed RFC3168 behaviour (i.e. propagating CE but stripping off ECT(1))
>>>
>>>
>>>  Yea, that was (I think), essentially my conclusion, long predating l4s and sce.
>>>
>>>  I am under the impression that ipsec tunneling actually doesn't do
>>>  even that much, by
>>>  default. Please feel free to correct my bad memories! but get some sleep!
>>>
>>>> Foo over UDP (and therefore Generic UDP Encap (GUE)) copied nothing on decap, just stripped the outer off.
>>>
>>>
>>>  a problem for both of your proposals.
>>>
>>>  My explorations LONG predate foo. so far as I know that was tom
>>>  herbert and facebook's thing
>>>  Is it deployed to any extent?
>>>
>>>>
>>>>  None copy ECT(1) from the outer when there's ECT(0) on the inner.
>>>
>>>
>>>  So I'm kind of confused now. But: ECT(1) on the inner does get copied
>>>  to the outer?
>>>
>>>  But: not the reverse?
>>>
>>>  I'd thought the nonce idea was sort of respected in the field,
>>>  and that NOT passing that along e2e kind of made sense. Or maybe the nonce idea
>>>  worried about the info leak too much?
>>>
>>>> The table of how it's meant to be done is even pasted from RFC6040 into comments, but the code doesn't actually do what the table says in the one case of an ECT(1) outer and ECT(0) inner.
>>>> https://github.com/torvalds/linux/blob/master/include/net/inet_ecn.h#L163
>>>
>>>
>>>  Sigh.
>>>
>>>>
>>>>  macOS/xnu-darwin propagates ECT(1) correctly per RFC6040.
>>>>  https://github.com/apple/darwin-xnu/blob/a449c6a3b8014d9406c2ddbdc81795da24aa7443/bsd/netinet/ip_ecn.c#L105
>>>
>>>
>>>  Good to know.
>>>
>>>  Easy patches throughout, but the long tail here is a decade+ long.
>>>
>>>>
>>>>
>>>>  Bob
>>>>
>>>>
>>>>  On Sun, Apr 26, 2020 at 4:57 PM Bob Briscoe <[e-mail]> wrote:
>>>>
>>>>  Jonathan, and other SCE contributors
>>>>
>>>>  This is one of the factors that strongly distinguishes L4S from SCE, so
>>>>  it's important.
>>>>
>>>>  In the slides you have contributed for tomorrow's tsvwg meeting, the
>>>>  question put by the chairs for #11 was:
>>>>  "ECT(1) propagation through current Internet (tunnels, lower layers). ":
>>>>
>>>>  The SCE responses regarding tunnels are:
>>>>  1.    "ECT(1) traverses the Internet well, due to foresight in RFC-3168.."
>>>>  2.    "Update to RFC-3168 desirable to obtain full benefits on tunnel path"
>>>>
>>>>  These sentences are both falsehoods.
>>>>
>>>>  Sentence #1:
>>>>  Where an AQM applies ECT(1) (SCE) marks to the outer headers of
>>>>  encapsulated packets, as an RFC3168 decapsulator strips off the outer
>>>>  header, all SCE marks will just disappear. It only propagates CE marking
>>>>  to the onward packet (which is one of the main reasons L4S solely uses
>>>>  CE as an output from the network).
>>>>
>>>>  Sentence #2:
>>>>  Without an update to RFC3168, there are no benefits from SCE on a tunnel
>>>>  path. So an update to RFC3168 is not merely desirable, it is essential,
>>>>  to obtain /any/ SCE-related benefit on a tunnel path.
>>>>
>>>>
>>>>  We need to get real here. This is not a research project. This is not a
>>>>  debating game. More than 50% of the Internet is now over mobile and all
>>>>  mobile networks use tunnels. Overlays and encapsulations are widely used
>>>>  over the rest of the Internet, to support v6 over v4, VPNs, retail over
>>>>  wholesale ISPs, virtual network overlays, etc, etc.
>>>>
>>>>  As you know, RFC6040 is the update to RFC3168 that SCE needs.
>>>>  Q1. Have you tested whether SCE works over tunnels that claim to comply
>>>>  with RFC6040?
>>>>  Q2. Have you attempted to measure the uptake of RFC6040 in tunnels over
>>>>  the Internet?
>>>>
>>>>
>>>>  Regards
>>>>
>>>>
>>>>
>>>>  Bob
>>>>
>>>>  --
>>>> ________________________________
>>>>  Bob Briscoe                               http://bobbriscoe.net/
>>>>
>>>>
>>>>
>>>>  --
>>>> ________________________________
>>>>  Bob Briscoe                               http://bobbriscoe.net/
>>>
>>>
>>>
>>>
>>>  --
>>>  Make Music, Not War
>>>
>>>  Dave Täht
>>>  CTO, TekLibre, LLC
>>>  http://www.teklibre.com
>>>  Tel: [phone]
>>
>>
>>
>>
>> --
>> Make Music, Not War
>>
>> Dave Täht
>> CTO, TekLibre, LLC
>> http://www.teklibre.com
>> Tel: [phone]
>>
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.



-- 
Make Music, Not War

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: [phone]