Re-sending trimmed to 40k > On 29 Jun 2021, at 17:16, Giles Heron <[email protected]> wrote: > > Hi Bob, > >> On 29 Jun 2021, at 16:55, Bob Briscoe <[email protected] >> <mailto:[email protected]>> wrote: >> >> Giles, >> >> On 29/06/2021 12:41, Giles Heron wrote: >>> Hi Bob, >>> >>>> On 28 Jun 2021, at 00:23, Bob Briscoe <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> Giles, Mark, >>>> >>>> On 10/06/2021 13:22, Giles Heron wrote: >>>>> So AFAIK SP networks don’t generally reorder packets in the steady state, >>>>> but of course reordering can occur under rerouting. >>>> >>>> [BB] The cases I'm concerned about are where the operator >>>> * deliberately reorders packets using a multi-queue scheduler at a node >>>> contrived to act as the bottleneck (the BNG) >>>> * AND the node is within an L2TPv2/3 tunnel >>>> * AND the tunnel needs sequencing at the egress for some other reason. >>> >>> If that’s the case then the node almost certainly won’t re-order packets >>> within the tunnel, even if it is deliberately reordering packets between >>> clients. As far as the node is concerned the L2TPv3 tunnel is one flow >>> within one subscriber’s traffic. BNG reordering is generally between >>> subscribers (e.g. where subscribers get serviced round-robin to ensure >>> fairness), or potentially within classes of service per subscriber (e.g. >>> strict priority for on-net voice and IPTV over Internet traffic). >> >> [BB] Not so. There are certainly cases where packets /are/ reordered within >> a per-customer tunnel. For instance, in the BT wholesale case, the BNG uses >> the BBF framework to schedule a set of QoS queues for each customer CVLAN. I >> know this intimately, because it was what I had been asked to simplify when >> we came up with L4S in the first place. Indeed, I was given permission to >> include a picture and description of it in this public report we did for the >> EU-funded project: >> https://riteproject.files.wordpress.com/2015/12/rite-deliverable-3-3-public1.pdf#12 >> >> <https://riteproject.files.wordpress.com/2015/12/rite-deliverable-3-3-public1.pdf#12> > > Yup - what I said. BNGs may reorder classes of service per sub. But one > L2TP tunnel where the endpoints are either side of the BNG ought to map to a > single CoS, right? And if it does then it won’t be reordered. > >> Also, there are probably many cases of accidental reordering too, e.g. due >> to channel bonding or multipath links that are left out of order rather than >> resequenced, or reroutes, including those at L7, when the traffic source >> moves to a CDN after a flow starts, etc. etc. > > Channel bonding and multipath links are generally set up very carefully NOT > to reorder packets within one flow. > > I covered rerouting in my original reply to you. > > And I think we can safely ignore CDNs in discussion of L2TP ;) > >> Whatever, the question is the converse: where packets are /not/ deliberately >> re-ordered by the network operator today, might these operators be >> sequencing IP data emerging from an L2TP tunnel? If so, they would have to >> disable sequencing if they wanted to introduce deliberate reordering (to >> transition to L4S). But (based partly on the insights you've given already) >> I doubt there is much if any sequencing going on of IP data over tunnels. > > Agreed. > > Giles > >>> >>>> >>>> In many cases, such a scheduler would be located prior to the tunnel >>>> ingress, so not a concern. I believe the DOCSIS rPHY case below falls into >>>> that category (both downstream and up). >>> >>> Agreed >>> >>>> >>>> In contrast, where a BNG sits /within/ the span of an L2TP tunnel, I think >>>> it will often (or at least sometimes?) have been constructed as the >>>> bottleneck. Any operator having designed such a QoS arrangement would not >>>> want to support sequencing... >>> >>> Yes, BNGs are often planned to be the bottleneck. But as I say that’s >>> about fairness between subscribers and potentially prioritising different >>> traffic for each subscriber. >>> >>>>> As noted by Derek I’m guessing reordering is an issue for L2TPv2 if >>>>> stateful PPP compression schemes are in play (which I suspect is unlikely >>>>> to be the case given we usually have abundant bandwidth in the >>>>> aggregation network, and given that compression can occur at other >>>>> layers). Though given that BNGs inherently keep state per subscriber >>>>> maybe the NPU scaling issues that Stewart mentioned are less of an issue >>>>> in that use case than for MPLS PEs doing PWE? >>>> >>>> My concern was that 'keep it simple' operators that are using L2TPv2/3 and >>>> had not previously bothered with the complexities of QoS might want to >>>> support L4S, because it has the potential to cut out queue delay for /all/ >>>> traffic. Altho' L4S is eventually for all traffic, it still requires two >>>> queues at the bottleneck for transition - one for L4S and one for >>>> not-yet-L4S ('Classic') traffic flows, and therefore introduces reordering >>>> at the aggregate level... >>> >>> Again I presume any single tunnel being passed *through* a BNG would either >>> be L4S or not-yet-L4S, and hence not subject to reordering? >> >> [BB] Not so, I'm afraid. L4S is enabled on a per-host basis, and during the >> transition, some traffic in the IP aggregate to (or from) a customer site >> will be L4S, and some Classic (not-yet-L4S). >> >> It's this reordering scenario that begged my original question - whether >> sequencing might be used anywhere for IP data over a tunnel. >> >> Cheers >> >> >> >> Bob >> >>> >>> Giles >>> >>>> >>>> From the replies so far, even if such 'keep it simple' operators were >>>> using compression, I can't see any reason why having to turn off >>>> compression and sequencing (in order to support L4S) would be a >>>> significant problem nowadays. >>>> >>>> So, in conclusion, I don't think we even need to raise any concerns about >>>> L2TP sequencing in the L4S specs. >>>> >>>> If anyone here thinks otherwise, pls speak now. >>>> >>>> Thank you everyone who has contributed to this discussion. >>>> >>>> Cheers >>>> >>>> >>>> >>>> Bob >>>> >>>> >>>> >>>>> >>>>> From a quick look at the DOCSIS rPHY specs it seems they do require >>>>> support for L2TPv3 sequence numbers. Of course in that case the payload >>>>> is the DOCSIS MAC rather than IP (even though, of course, most DOCSIS >>>>> frames ultimately carry an IP payload). >>>>> >>>>> Giles >>>>> >>>>>> On 10 Jun 2021, at 12:49, Andrew G. Malis <[email protected] >>>>>> <mailto:[email protected]>> wrote: >>>>>> >>>>>> (resending with cc: list trimmed to pass the too many recipients filter) >>>>>> Mark, >>>>>> >>>>>> The original question was, how many (if any) of these L2TPv2 and v3 use >>>>>> cases use sequencing, especially when carrying IP? >>>>>> >>>>>> Cheers, >>>>>> Andy >>>>>> >>>>>> On Wed, Jun 9, 2021 at 6:32 PM Mark Townsley <[email protected] >>>>>> <mailto:[email protected]>> wrote: >>>>>> Hi folks, >>>>>> >>>>>> In addition to the DSL arena, L2TP is still in use with host-based VPN >>>>>> clients as it is embedded in Apple, Android, and Windows based operating >>>>>> systems (new and old). Despite most VPN solutions preferring their own >>>>>> client software that must be installed on hosts to operate, there are >>>>>> still admins that appreciate not having to ask their employees to >>>>>> download an app for the VPN to work - in which case PPTP and L2TP with >>>>>> transport-mode IPsec are your most widely available options. >>>>>> >>>>>> Regarding L2TPv3 replacing L2TP: L2TPv2 (RFC 2661) was PPP only. L2TPv3 >>>>>> generalized L2TP to support other L2 (including MPLS, but I don’t want >>>>>> to argue what layer MPLS operates within here). There was never a strong >>>>>> push to replace L2TPv2 used in DSL, Dialup and host VPN software with >>>>>> L2TPv3 (there was one use case for an important L2TP operator that >>>>>> wanted to carry PPPoE over L2TPv3 in DSL, but that was overcome by >>>>>> RFC3817 which achieved the same goal without altering the dataplane). >>>>>> Ironically, I would expect to see very little PPP over L2TPv3 in the >>>>>> wild, though obviously it is possible. >>>>>> >>>>>> In the cable broadband world, the DOCSIS DEPI “Remote PHY” specification >>>>>> (similar I suppose to the split BNG spec Joel is referring to) >>>>>> standardized on L2TPv3 and is in active use. >>>>>> >>>>>> I also know of at least one vendor that uses Ethernet over L2TPv3 for >>>>>> some wifi backhaul use cases. >>>>>> >>>>>> There could be more, this is just what I am personally aware of off the >>>>>> top of my head. Even I am surprised to see how much L2TP is still out >>>>>> there once you start really looking around ;-) >>>>>> >>>>>> Best Regards, >>>>>> >>>>>> - Mark >>>>>> >>>>>> >>>>>> >>>>>> >
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
