Subject: [Banana] Reaching Consensus on Problem Statement

From: Margaret Cullen <[email-masked]>
Date: Thu, 2 Feb 2017 11:48:34 -0500

At the BANANA BOF in November, we did not seem to have clear consensus on a concise problem statement.  So, I’d like to try to reach consensus on a problem statement on this list, in the hopes that we can (finally!) move forward towards work on solutions.   To that end, I’ve been working with multiple people over the past few weeks to come up with a concise problem statement for our expanded BANANA effort (as represented at the BOF), and I have determined that the main aspects of the problem we are trying to solve are:

(1) Unmanaged networks (i.e. homes or small offices) often have more than one point of attachment to the Internet (DSL, Cable, LTE, etc).  We call these networks “multi-access networks”.  In multi-access networks, it is desirable to utilize the bandwidth of all attached networks to increase performance.  We call this “bandwidth aggregation”.

(2) An unmanaged multi-access network may have multiple links from a single provider (e.g. DSL/LTE, or two LTE links), or multiple links from different providers (e.g. Cable & LTE, or DSL and LTE from different providers).   We need a solution that will work in both cases, without requiring cooperation between multiple providers.  Therefore, our solution needs to work with existing IP address assignment, ingress filtering, and reverse path routing mechanisms.

(3) In these environments, the available paths to the Internet may change over time due to changing conditions and/or service outages.  It would be desirable for all existing sessions to continue using the remaining link(s) when a link becomes unavailable or unreliable.  We call this “failover”.  [Note:  This is especially true when you consider the possibility that, using this mechanism, people could increase the bandwidth available wherever they are by routinely using their smart phones as Wifi access points accessible to their home or office CPE, PCs or laptops.]

(4) Homes and small offices tend to have few simultaneous sessions active at any given time, and may often have only one large, relatively long-lived session in use for an online game or media download.  Despite the fact that only one session may be active, end-users would still benefit from increased bandwidth and reliability for that single session.  It is therefore important to support bandwidth aggregation and failover for a single session (i.e. a single TCP connection or UDP flow).  This is a key point that distinguishes the BANANA problem from other flow-based load sharing and site multihoming problems.

Thoughts?  Comments?  Do you think this problem statement is clear and understandable?  If not, in what way is it unclear?  All comments from major rewrites to word-smithing are welcome!

I’ll wait a week for feedback, then I’ll update this problem statement based on any comments I have received from this list.  After that, I will make a formal consensus call on the list, in the hope of confirming that we have consensus, among ourselves at least, regarding the problem we are trying to solve.

Margaret

---

From: Michael Menth <[email-masked]>
Date: Thu, 2 Feb 2017 19:53:29 +0100

Dear Margaret,

thanks a lot for your initiative!

The scope may depend on where the load balancer and recomination point
are located. In the network similar to
draft-zhang-gre-tunnel-bonding-01.txt (GRE Tunnel Bonding) or
MPTCP-Proxy, or on the endpoints like pure MPTCP? Probably focus is on
the first, but the text doesn't say so, yet.
I can imagine that the load balancing option (per-packet or per-flow)
may be minor. Both may be justified for performance reasons depending on
networking conditions. Therefore, I wouldn't rule out per-flow load
balancing but a priority on per-packet may be reasonable to start with.

Regards,

Michael

Am 02.02.2017 um 17:48 schrieb Margaret Cullen:
> _______________________________________________
> Banana mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/banana
> 

-- 
Prof. Dr. habil. Michael Menth
University of Tuebingen
Faculty of Science
Department of Computer Science
Chair of Communication Networks
Sand 13, 72076 Tuebingen, Germany
phone: (+49)-7071/29-70505
fax: (+49)-7071/29-5220
mailto:[email-masked]
http://kn.inf.uni-tuebingen.de

---

From: Mingui Zhang <[email-masked]>
Date: Fri, 3 Feb 2017 09:38:18 +0000

Hi Margaret,

Thanks for bringing this out!

This is a very clear statement of the problem we are currently facing. The motivations have been well explained. The unique feature about bandwidth aggregation for a single session is addressed so that people will not mistake it for the traditional flow-based load sharing any more.

A minor comment is inserted inline below.

Regards,
Mingui

> -----Original Message-----
> From: Banana [mailto:[email-masked]] On Behalf Of Margaret Cullen
> Sent: Friday, February 03, 2017 12:49 AM
> To: [email-masked]
> Subject: [Banana] Reaching Consensus on Problem Statement
> 
> At the BANANA BOF in November, we did not seem to have clear consensus on a
> concise problem statement.  So, I’d like to try to reach consensus on a problem
> statement on this list, in the hopes that we can (finally!) move forward towards
> work on solutions.   To that end, I’ve been working with multiple people over
> the past few weeks to come up with a concise problem statement for our
> expanded BANANA effort (as represented at the BOF), and I have determined
> that the main aspects of the problem we are trying to solve are:
> 
> (1) Unmanaged networks (i.e. homes or small offices) often have more than one
> point of attachment to the Internet (DSL, Cable, LTE, etc).  We call these
> networks “multi-access networks”.  In multi-access networks, it is desirable to
> utilize the bandwidth of all attached networks to increase performance.  We call
> this “bandwidth aggregation”.
> 
> (2) An unmanaged multi-access network may have multiple links from a single
> provider (e.g. DSL/LTE, or two LTE links), or multiple links from different providers
> (e.g. Cable & LTE, or DSL and LTE from different providers).   We need a solution
> that will work in both cases, without requiring cooperation between multiple
> providers.  Therefore, our solution needs to work with existing IP address
> assignment, ingress filtering, and reverse path routing mechanisms.
> 
> (3) In these environments, the available paths to the Internet may change over
> time due to changing conditions and/or service outages.  It would be desirable
> for all existing sessions to continue using the remaining link(s) when a link
> becomes unavailable or unreliable.  We call this “failover”.  [Note:  This is
> especially true when you consider the possibility that, using this mechanism,
> people could increase the bandwidth available wherever they are by routinely
> using their smart phones as Wifi access points accessible to their home or office
> CPE, PCs or laptops.]

Here, it means “home or office CPE, PCs or laptops” are connected to the smart phone while the smart phone is sharing its Internet access (through its data plans, airport Wifis, etc) as an AP. It does not mean the opposite direction that ”home or office CPE, PCs or laptops” are providing Internet access to the smart phone while this smart phone is sharing its Internet access to other possible end devices. Am I correct? I know the first case is a quite ordinary use case when people are traveling.

> 
> (4) Homes and small offices tend to have few simultaneous sessions active at any
> given time, and may often have only one large, relatively long-lived session in use
> for an online game or media download.  Despite the fact that only one session
> may be active, end-users would still benefit from increased bandwidth and
> reliability for that single session.  It is therefore important to support bandwidth
> aggregation and failover for a single session (i.e. a single TCP connection or UDP
> flow).  This is a key point that distinguishes the BANANA problem from other
> flow-based load sharing and site multihoming problems.
> 
> Thoughts?  Comments?  Do you think this problem statement is clear and
> understandable?  If not, in what way is it unclear?  All comments from major
> rewrites to word-smithing are welcome!
> 
> I’ll wait a week for feedback, then I’ll update this problem statement based on
> any comments I have received from this list.  After that, I will make a formal
> consensus call on the list, in the hope of confirming that we have consensus,
> among ourselves at least, regarding the problem we are trying to solve.
> 
> Margaret
> 
>

---

From: Mingui Zhang <[email-masked]>
Date: Fri, 3 Feb 2017 09:40:42 +0000

Hi Michael, 

> From: Banana [mailto:[email-masked]] On Behalf Of Michael Menth
> Sent: Friday, February 03, 2017 2:53 AM
> To: [email-masked]
> Subject: Re: [Banana] Reaching Consensus on Problem Statement
> 
> Dear Margaret,
> 
> The scope may depend on where the load balancer and recomination point are
> located. In the network similar to draft-zhang-gre-tunnel-bonding-01.txt (GRE
> Tunnel Bonding) or MPTCP-Proxy, or on the endpoints like pure MPTCP?
> Probably focus is on the first, but the text doesn't say so, yet.

According to my understanding, the scope might as well be applicable to the network with MPTCP-Proxy. And surely, it does not include the network with pure MPTCP endpoints.

> I can imagine that the load balancing option (per-packet or per-flow) may be
> minor. Both may be justified for performance reasons depending on networking
> conditions. Therefore, I wouldn't rule out per-flow load balancing but a priority
> on per-packet may be reasonable to start with.

But there are solutions for per-flow load sharing already. Think about the widely used and standardized hashing methods. I think it’s non-necessary to mention per-flow load sharing issue in the problem statement. Otherwise, the problem statement would look like encouraging reinventing something.

> Michael

Thanks,
Mingui

> > At the BANANA BOF in November, we did not seem to have clear consensus on
> a concise problem statement.  So, I’d like to try to reach consensus on a
> problem statement on this list, in the hopes that we can (finally!) move forward
> towards work on solutions.   To that end, I’ve been working with multiple
> people over the past few weeks to come up with a concise problem statement
> for our expanded BANANA effort (as represented at the BOF), and I have
> determined that the main aspects of the problem we are trying to solve are:
> >
> > (1) Unmanaged networks (i.e. homes or small offices) often have more than
> one point of attachment to the Internet (DSL, Cable, LTE, etc).  We call these
> > (3) In these environments, the available paths to the Internet may
> > change over time due to changing conditions and/or service outages.
> > It would be desirable for all existing sessions to continue using the
> > remaining link(s) when a link becomes unavailable or unreliable.  We
> > call this “failover”.  [Note:  This is especially true when you
> > consider the possibility that, using this mechanism, people could
> > increase the bandwidth available wherever they are by routinely using
> > their smart phones as Wifi access points accessible to their home or
> > office CPE, PCs or laptops.]
> >
> > (4) Homes and small offices tend to have few simultaneous sessions active at
> any given time, and may often have only one large, relatively long-lived session in
> use for an online game or media download.  Despite the fact that only one
> session may be active, end-users would still benefit from increased bandwidth
> and reliability for that single session.  It is therefore important to support
> bandwidth aggregation and failover for a single session (i.e. a single TCP
> connection or UDP flow).  This is a key point that distinguishes the BANANA
> problem from other flow-based load sharing and site multihoming problems.
> >
> > I’ll wait a week for feedback, then I’ll update this problem statement based
> on any comments I have received from this list.  After that, I will make a formal

---

From: Brian Trammell <[email-masked]>
Date: Fri, 3 Feb 2017 11:09:15 +0100

hi Mingui, Michael, all,

inline below...

> On 03 Feb 2017, at 10:40, Mingui Zhang <[email-masked]> wrote:
> 
> Hi Michael,
> 

Speaking personally, no Seoul-BoF-chair or other hats on:

Let me slightly restate the question here. Will a BANANA-balanced network with two links to the Internet with available downstream data rates A and B (such that A >= B) will ever need to support a single flow with a sustained data rate > A?

If not, we can take existing work on per-flow load balancing off the self. If so, we need to invent something.

In scenarios where there is no dominant flow, or where A >> B, the extra complexity of splitting flows across links is not worth the additional complexity. However, in scenarios where one flow dominates, i.e., the majority of the data rate demand is covered by a single flow, and where rates A and B are relatively comparable, per-flow load balancing leaves a lot of available bandwidth on the table, and the complexity tradeoff becomes more worth it.

So for me this question reduces to which scenario is more common.

Cheers,

Brian

---

From: Brian Trammell <[email-masked]>
Date: Fri, 3 Feb 2017 11:11:01 +0100

hi Margaret,

Thanks a lot for pulling this together -- this, I think, concisely and accurately reflects the intersection of the problem spaces discussed in the BoF that we should explore further.

Cheers,

Brian (no hats)

> On 02 Feb 2017, at 17:48, Margaret Cullen <[email-masked]> wrote:
>

---

From: Mirja Kühlewind <[email-masked]>
Date: Fri, 3 Feb 2017 11:14:47 +0100

Hi Margaret,

thanks for starting this discussion. Here are some personal thoughts:

> Am 02.02.2017 um 17:48 schrieb Margaret Cullen <[email-masked]>:
> 
This is related to point 4 and combining both is the interesting problem from my point of view. If you have multiple flows and multiple interfaces, it's rather easy to simply route/schedule different flows over different links (a la ECMP). The problem comes up if you have a service with one flow that needs more capacity than a single link can provide. The example we’ve been working on is HD video streaming in rural areas where the DSL is limited but LTE is provided and sparely used. In this case you need re-oder buffers and additional signaling between the tunnel endpoints.

> (2) An unmanaged multi-access network may have multiple links from a single provider (e.g. DSL/LTE, or two LTE links), or multiple links from different providers (e.g. Cable & LTE, or DSL and LTE f…

This is not fully clear to me. I don’t think it's important who owns the link (I mean if you buy connectivity from one provider you can just use it); it’s important who owns the proxies. And the ingress proxy can only be own by one party (because it’s one box) however that box can simply use connectivity from different providers. I don’t see a problem there. The more interesting case is if the ingress and the egress proxy are not owned by the same party because this is the case where a proprietary protocol to exchange information between those two boxes would not work anymore. 

> (3) In these environments, the available paths to the Internet may change over time due to changing conditions and/or service outages.  It would be desirable for all existing sessions to continue u…

I don’t think this is that important. I believe failover will likely be cover implicitly and if not it might be a completely different problem (than bandwidth aggregation).

> (4) Homes and small offices tend to have few simultaneous sessions active at any given time, and may often have only one large, relatively long-lived session in use for an online game or media down…

See above.

Also having an agreement for the problem is of course the first step. Howeve,r my understanding from the BoF was that there are already quite a bunch of people working on different solutions. So what’s really needed is agreement on the solution (and if there is one for all or different things or multiple solutions  are needed). Only if there is a first proposal for one (or more?) protocol(s) that this group would work on, it makes sense to think about chartering.

Mirja

---

From: Jim Reid <[email-masked]>
Date: Fri, 3 Feb 2017 10:15:53 +0000

> On 3 Feb 2017, at 10:11, Brian Trammell <[email-masked]> wrote:
> 

+1

---

From: Margaret Cullen <[email-masked]>
Date: Fri, 3 Feb 2017 10:45:34 -0500

> On Feb 3, 2017, at 5:14 AM, Mirja Kühlewind <[email-masked]> wrote:
> 
> Hi Margaret,
>> 

This is an interesting way of putting it — that a single flow needs more bandwidth than a single link can provide.  I think I would say, though, that this is useful when a single flow needs _or can benefit from_ more bandwidth than a single link provides, because a solution is also desirable in this area to allow, for example, content downloads to finish more quickly, even if they do not _need_ to finish more quickly in order to be useful.  Does that make sense?

Margaret

---

From: Margaret Cullen <[email-masked]>
Date: Fri, 3 Feb 2017 10:57:21 -0500

Hi Mirja,

> Also having an agreement for the problem is of course the first step. Howeve,r my understanding from the BoF was that there are already quite a bunch of people working on different solutions. So wh…

I agree that we also need to reach consensus, as a group, on how to move forward on one or more solutions, but I don’t think we can move forward on solutions until we have:

- Consensus that we have a well-understood problem statement, and
- Consensus that we think the problem is something it would be useful for the IETF to work on.

Once we have agreement on those things, we can discuss whether it makes sense to standardize only a single solution to this problem, or whether the trade-offs between different solutions mean that more than one solution may be needed for different deployment scenarios.

Does that make sense?

Margaret

---

From: Margaret Cullen <[email-masked]>
Date: Fri, 3 Feb 2017 10:59:51 -0500

Hi Mirja,

> This is not fully clear to me. I don’t think it's important who owns the link (I mean if you buy connectivity from one provider you can just use it); it’s important who owns the proxies. And the in…

I included this paragraph because this was the subject of much discussion, and a scope change, leading into the BOF.  Maybe this is more like a requirement for solutions, though, than part of the actual problem statement.   I agree with you that items (1) and (4) in my original list are the crux of the interesting problem we are trying to solve, and I will work on simplifying the problem statement accordingly.

Margaret

---

From: Mirja Kühlewind <[email-masked]>
Date: Fri, 3 Feb 2017 17:52:30 +0100

Yes, that's right, also increasing the total bandwidth (for adaptive traffic) is a use case.

> Am 03.02.2017 um 16:45 schrieb Margaret Cullen <[email-masked]>:
> 
>

---

From: Mirja Kühlewind <[email-masked]>
Date: Fri, 3 Feb 2017 17:54:24 +0100

Hi,

I do agree, but…

> Am 03.02.2017 um 16:57 schrieb Margaret Cullen <[email-masked]>:
> 
> Hi Mirja,
> 

I had the feeling there was already a good understanding of the problem in the BoF.

> - Consensus that we think the problem is something it would be useful for the IETF to work on.

This depends on the solution rather than the problem…

Mirja

---

From: Margaret Cullen <[email-masked]>
Date: Fri, 3 Feb 2017 12:27:11 -0500

> On Feb 3, 2017, at 11:54 AM, Mirja Kühlewind <[email-masked]> wrote:
> 
> Hi,
> 
> I do agree, but…
> 
> 

Sadly, when we asked the question at the BOF “Is the problem statement well-understood?”, quite a few people said that they did not understand it.  I was frustrated with this, because the problem has been well-understood on our mailing list, and in side meetings for quite a while, and I don’t know what it is that people at the BOF found hard to understand about it.  Suresh indicated, though, that he wanted us to get agreement on the list that we have a well-understood problem statement, so that is what I am trying to do.

I do sort of feel like the best way to stop work in the IETF would be to pack a BOF with high school students who are willing to raise their hands and say that they don’t understand the problem…  There were lots of people there who did say that they understood the problem, but because we did not have consensus that the problem was well-understood by everyone in the room, we couldn’t ask the people who do understand the problem whether they think we should work on it in the IETF, or what approach we should take to solve it.

I’m hopeful that if we can get agreement on a well-understood problems statement here on the list, we can ask those questions here, within an open group of people who actually care about this problem, and move ahead.

Margaret

---

From: Mingui Zhang <[email-masked]>
Date: Sat, 4 Feb 2017 06:50:47 +0000

Hi Brian,

Please see my comments inline below.

> From: Banana [mailto:[email-masked]] On Behalf Of Brian Trammell
> Sent: Friday, February 03, 2017 6:09 PM
> To: Mingui Zhang
> Cc: Michael Menth; [email-masked]
> >> The scope may depend on where the load balancer and recomination
> >> point are located. In the network similar to
> >> draft-zhang-gre-tunnel-bonding-01.txt (GRE Tunnel Bonding) or MPTCP-Proxy,
> or on the endpoints like pure MPTCP?
> > According to my understanding, the scope might as well be applicable to the
> network with MPTCP-Proxy. And surely, it does not include the network with
> pure MPTCP endpoints.
> >
> >> may be minor. Both may be justified for performance reasons depending
> >> on networking conditions. Therefore, I wouldn't rule out per-flow
> >> load balancing but a priority on per-packet may be reasonable to start with.
> >
> > But there are solutions for per-flow load sharing already. Think about the
> widely used and standardized hashing methods. I think it’s non-necessary to
> mention per-flow load sharing issue in the problem statement. Otherwise, the
> problem statement would look like encouraging reinventing something.
> 
> Let me slightly restate the question here. Will a BANANA-balanced network with
> two links to the Internet with available downstream data rates A and B (such that
> A >= B) will ever need to support a single flow with a sustained data rate > A?

Yes, this is needed. 

> need to invent something.

Here, do you mean "per-packet" rather than "existing work on per-flow"? Sorry, I am confused since "a single flow with data rate > A" can only be achieved through per-packet load splitting. 
Michael and I had no doubt that per-packet is necessary in the first place. We were actually arguing whether per-flow should be additionally included in the problem statement. 

> 
> In scenarios where there is no dominant flow, or where A >> B, the extra
> complexity of splitting flows across links is not worth the additional complexity.
> However, in scenarios where one flow dominates, i.e., the majority of the data
> rate demand is covered by a single flow, and where rates A and B are relatively
> comparable, per-flow load balancing leaves a lot of available bandwidth on the
> table, and the complexity tradeoff becomes more worth it.

After I read up to here, I understand you are describing why BANANA need to "split" flows in addition to per-flow load balancing. Then we are on the same page. 

By the way, the formulation of the scenario is awesome.

Thanks,
Mingui

---

From: Michael Menth <[email-masked]>
Date: Sat, 4 Feb 2017 14:06:17 +0100

Hi Mingui,

> But there are solutions for per-flow load sharing already. Think about the widely used and standardized hashing methods. I think it’s non-necessary to mention per-flow load sharing issue in the pro…
That is right. But they may be inefficient in the presence of only a few
flows as they are distributed randomly accross paths without respecting
available resources. I can imagine that this situation could benefit
from Banana. It's certainly not a primary goal for Banana, but a
solution also solving this inefficiency could be a plus.

Regards,

Michael

---

From: Alan Ford <[email-masked]>
Date: Sat, 4 Feb 2017 21:00:03 +0000

Hi Margaret, all,

Thanks for picking this up. The problem statement as written below indeed gives a clear high-level overview of the scenario, although one point I’d make is that point 4 appears to me to be simply a corollary to point 1 (i.e. “and this includes aggregating for a single session”).

One observation is that I think it is implied that this requires some kind of device in the network to assist with these scenarios (since otherwise end-to-end MPTCP would solve most of this for stream-based transports), but this is not stated. The problem with this broadness is that who the problem would be solved for could lead to a considerably different solutions (e.g. solving for network providers would potentially lead to different scenarios to hosting providers, which in turn which would be different to those for third-party service providers), and similarly ownership/management of the various enabling devices (CPE, concentrator, etc).

Brian describes this as an “intersection of the problem spaces”, but it was this lack of specificity in the commonality between the presented scenarios which I think led to at least some of the confusion in the BOF. Some of the scenarios presented could be solved with existing technologies with minimal changes, but these may not apply to other scenarios. So is the goal here going to be to try to provide a generic solution? Or one or more solutions more specific to certain problems? Can the problem statement in some way be more focused on a particular scenario or set of scenarios which have commonality (e.g. two constraints could be: the existence of a terminating proxy within the network, and no requirement for manual configuration at the CPE end - both would significantly focus the work; if management commonality could also be established (or defined) that would also focus the solution space).

Regards,
Alan

> On 2 Feb 2017, at 16:48, Margaret Cullen <[email-masked]> wrote:
>

---

From: Joe Touch <[email-masked]>
Date: Mon, 6 Feb 2017 11:12:50 -0800

On 2/4/2017 1:00 PM, Alan Ford wrote:
> One observation is that I think it is implied that this requires some
> kind of device in the network to assist with these scenarios (since
> otherwise end-to-end MPTCP would solve most of this for stream-based
> transports), but this is not stated.

It seems like it requires *two* such devices (tunnel endpoints) to make
this work.

The point is that you're essentially hiding dynamic multipath routing
inside what looks like a tunnel (which looks like a link).

I.e., this is really just a recursive router (of which LISP is one
example) with two edge devices.

There are other considerations, e.g., this has more potential impact on
reordering and less problems with egress determination for new flows
(since there's only one egress in each direction), but there might be
useful similarities to consider, FWIW.

Joe

---

From: <[email-masked]>
Date: Wed, 8 Feb 2017 10:58:09 +0000

Hi,

Von: Banana [mailto:[email-masked]] Im Auftrag von Margaret Cullen
Gesendet: Freitag, 3. Februar 2017 16:46
An: Mirja Kühlewind
Cc: [email-masked]
Betreff: Re: [Banana] Reaching Consensus on Problem Statement

On Feb 3, 2017, at 5:14 AM, Mirja Kühlewind <[email-masked]<mailto:[email-masked]>> wrote:

Hi Margaret,

I think for links with smaller bandwidth this is a very valid scenario (e.g. if you do have 4+4 or 6+6 MBit/s). In this case you benefit from the additional bandwidth and it is very likely that we will have services exceeding the bandwidth of a single link (like the HD scenario mentioned above).

Regards

Nic

---

From: Margaret Cullen <[email-masked]>
Date: Wed, 8 Feb 2017 06:35:12 -0500

Hi Joe,

> On Feb 6, 2017, at 2:12 PM, Joe Touch <[email-masked]> wrote:
> 

Yes.  The things I think we can standardize here are how the two devices (securely) communicate, how data is encapsulated between them, what traffic they should bypass, and how they should transform packets on ingress/egress so that they are transparent to non-multi-access-aware end-nodes.  In other words, the things that would need to be standardized for the devices on the two ends of a single BANANA connection to be manufactured by different vendors.

One interesting thing to consider is that there will be two devices involved for any one flow, but if we envision a solution to the end-to-end scenario described in the BOF, the two devices might be two CPE devices, in which case the CPE device in a home with more than one flow might have BANANA connections to more than one remote device, up to one per flow.  This scenario is not covered by any of the current solution proposals, but some of them could be (fairly easily?) extended to cover it.

> useful similarities to consider, FWIW.

Yes, I agree.

Margaret