Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-id-18.txt

[Bob Briscoe <[e-mail]>]

Derek,

Thanks again for digging into this. I'm beginning to realize this sort 
of thing is not really for the current drafts, which are focused on 
implementation requirements. Configuring sequencing is more advice for 
running the L4S experiment. I have seen offlist discussions about 
starting such a draft (l4sops scope is purely about the coexistence 
issue, so not an appropriate place). So if advice about sequencing goes 
anywhere, it ought to go in an ops guidance draft about running L4S 
experiments.

Like you say, the question is determining the degree of use. If the odd 
(misguided?) user is going to turn on compression in their VPN, and then 
possibly need sequencing (depending on what type of compression they are 
using), they won't get the benefit of low delay while some of their 
traffic is Classic, because the sequencing will hold back the L4S until 
the Classic catches up. That's their choice, and I doubt they are going 
to benefit from the RFCs advising them not to screw up.

Again, we can add such advice if the WG wants. But I'd like to see more 
pressure to do so before we complicate any of the L4S drafts even further.


Bob

On 15/07/2021 22:57, Derek Fawcus wrote:
> On Thu, Jul 01, 2021 at 01:45:05PM +0100, Bob Briscoe wrote:
>>    * After consulting with the int-area
>>      <https://mailarchive.ietf.org/arch/msg/int-area/y5UmhfSAka7xi_iBvX50bZ0jxzQ/>
>>      and PALS
>>      <https://mailarchive.ietf.org/arch/msg/pals/iWxEpj0MB-Du_U8KjelIocbg6Yk/>
>>      lists (follow the links for the relevant long threads), it was
>>      decided there is no need to mention that tunnels that support
>>      resequencing like L2TP should have it disabled for data channels
>>      carrying L4S traffic (because there's no evidence that any would
>>      enable sequencing for IP data - sequencing is generally for the
>>      tunnel control channel or for stateful header compression that
>>      nowadays hinders rather than helps performance).
> While that was the service provider view, it is not the only deployment
> of L2TP.  So I'm not sure that this is a safe assumption, as one of the
> cases I believe I mentioned in that thread is the Microsoft RAS VPN product.
>
> It has at least two forms, PPTP (IP/PPP/GREv1) and L2TP/IPsec (IP/PPP/L2TP/ESP).
> Both forms can make use of sequence numbers in their encapsulation.
>
> I know the PPTP version is still actively being used, as we recently ended
> up adding an ALG for it to our CGNAT software, due to requests.
>
> We used to support use of the L2TP form in our product around 3 years ago,
> so it was still in use then.  It could well still be in use, as it often
> 'just works' through NATs since its ESP has a version of UDP NAT-Traversal.
>
> Last I played with these, the MS version offered the ability to enable
> compression, which I believe included IP header compressions, and so may
> be reordering sensitive.
>
> The problem here would be in determining the degree of use, and if people
> (usually not being specialists) have enabled compression.  Certainly one
> place I worked at some years ago had enabled compression, that was by
> someone who just viewed compression as good.  This was a SME, which seems
> to be the usual use case.
>
> DF
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/