Subject: [babel] Standardizing price advertisements for Babel

From: Justin Kilpatrick <[email-masked]>
Date: Sun, 12 Nov 2017 12:51:23 -0500

I have a half written RFC [0] about how to propagate real-currency
routing prices in Babel. 

You may remember a non-standards compliant version of this I made of
this to familiarize myself with Babel [1]. I posted it to the users list
back in September [2].

While 'one currency to rule them all' is common in blockchain projects I
wanted a more flexible standard. So the prices for the route are moved
to a subtlv on the updates. We also make a new update tlv solely to
carry this subtlv. Otherwise standards compliant Babel instances unaware
of pay-per-forward would ignore the unknown subtlv's and attempt to
route traffic without payment. 

The net effect here is just operating two parallel Babel networks. One
paid and one free, furthermore since currency has to agree along paid
paths there are even more networks within the paid set. 

The main concern here is bloated routing tables. Juliusz has suggested
price aggregation previously [3]. After playing around with a hacky
market simulator [4] I've reached the conclusion that this would be
effective in the common case and easy enough to do on local copies of
the routing tables. But I'm hesitant to build that sort of aggregation
into the network format for complexity reasons.

What I'm most interested in right now is how the community feels about
parallel sets of routing tables and even subtables per currency. Is a
more limited system better simply because a fully utilized arbitrary
currency system would be too inefficient? 

[0]
https://github.com/althea-mesh/babel-drafts/blob/master/draft-ietf-babel-price-propagation/draft-ietf-babel-price-propagation.xml
[1]
https://github.com/althea-mesh/babeld/commit/4e88ef5eab18afcadfdd3739c4637de7e62d76a0
[2]
https://lists.alioth.debian.org/pipermail/babel-users/2017-September/002915.html
[3]
https://lists.alioth.debian.org/pipermail/babel-users/2017-September/002919.html
[4] https://gist.github.com/jkilpatr/ec142833a0c2f09de01b37a83a5f78d2
-- 
  Justin Kilpatrick
  [email-masked]

---

From: Gabriel Kerneis <[email-masked]>
Date: Mon, 13 Nov 2017 10:03:42 +0100

> currency system would be too inefficient?

I don't know anything about pricing routing tables, but I know that you
should in general not try to generalize an idea based on zero example. Do
you have at least one concrete example in mind where such a multi-currency
setup would be useful? If so, it would help inform the discussion if you
could describe it here. Otherwise, it's a strong hint that a more limited
system would be enough. (Also remember that this WG has a tradition of
implementing what it aims at normalizing, and you would need not only to
implement but also test this system—without a use-case, that is going to be
tricky.)

Gabriel

---

From: Justin Kilpatrick <[email-masked]>
Date: Mon, 13 Nov 2017 07:18:01 -0500

Ah thanks for pointing that out. So right now we envision using a
dollar-coin or some other national currency backed crypto to pay for
traffic in the mesh.

Because handing devices to non-technical people that expose them to the
volatility of cryptocurrency isn't really useful or ethical. What do we
tell them when their internet tokens are worth half of what they where
worth yesterday?

On the other hand if people want to exchange in more traditional and
speculative cryptocurrency that's their choice. 

As another consideration, what if we iterate the rules of billing so
dramatically that the entire path needs the new system to operate? At
that point we would make a new currency code for the same currency
because the way it is exchanged is different enough that it needs to be
versioned. 

Previously I had separate 8bit fields for a payment rules version and a
8bit currency code, but 256 rules updates seems too many and 256
possible currencies seems too few. 

The usecases don't provide a compelling reason to need more than maybe 4
- 8 currency sub-tlv's. Assuming two or three major methods of exchange
and two sets of billing rules active for each as an update rolls out.
Perhaps the number can simply be arbitrarily limited?  

--
  Justin Kilpatrick
  [email-masked]

On Mon, Nov 13, 2017, at 04:03 AM, Gabriel Kerneis wrote:
> 
> On Sun, Nov 12, 2017 at 6:51 PM, Justin Kilpatrick <[email-masked]> wrote: 
> I don't know anything about pricing routing tables, but I know that you should in general not try to generalize an idea based on zero example. Do you have at least one concrete example in mind where such a multi-currency setup would be useful? If so, it would help inform the discussion if you could describe it here. Otherwise, it's a strong hint that a more limited system would be enough. (Also remember that this WG has a tradition of implementing what it aims at normalizing, and you would need not only to implement but also test this system—without a use-case, that is going to be tricky.)
> 
> Gabriel

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 13 Nov 2017 16:28:25 +0100

> to a subtlv on the updates.

Makes sense.  (Note that you called your field "price per byte" -- what if
a given pricing model involves "price per packet" or "price per unit of
airtime"?).

> We also make a new update tlv solely to carry this subtlv. Otherwise
> standards compliant Babel instances unaware of pay-per-forward would
> ignore the unknown subtlv's and attempt to route traffic without
> payment.

That's true in RFC 6126.  In rfc6126bis, there is a new feature, the
mandatory bit, which is designed to handle cases exactly like this one.
If an unknown mandatory sub-TLV is encountered, the whole enclosing TLV is
dropped, just like you suggest.

However, I'm not sure that this is the right approach.  I would suggest
that you use a normal Update carrying the metric of the free path, and
a sub-TLV that carries both the cost and the metric of the paid route.  If
a given node does not advertise a free route, the TLV's metric is set to
infinity.

In short:

  your encoding:  <Update metric=42> <Paid-Update metric=57 <pay cost=93>>

  suggested encoding: <Update metric=42 <pay metric=57 cost=93>>

and

  your encoding: <Paid-Update metric=57 <pay cost=93>>

  suggested encoding <Update metric=FFFF <pay metric=57 cost=94>>

> The net effect here is just operating two parallel Babel networks.

I think this statement is ambiguous, and I suggest you remove it from your
draft.  There's just one set of neighbour relationships, and the router
carry two parallel sets of updates.

> parallel sets of routing tables and even subtables per currency.

Babel has had the ability to carry mutliple sets of routes since very
early in its history -- it was originally an IPv6-only protocol, but
learned to carry IPv4 a mere few months after its inception (we were doing
IPv4-in-IPv6 tunnels before it was fashionable).  Both the source-specific
and ToS-specific extensions can be modelled as using multiple tables.

Another point.  Perhaps I've missed something, but you don't seem to
define the semantics of a single Update carrying multiple Pay sub-TLVs.
Does it mean that you get to (1) pay one of those, at your choise, (2) pay
one of those, at the network's choice, or (3) the sum?  I think this
deserves defining precisely.

-- Juliusz

---

From: Justin Kilpatrick <[email-masked]>
Date: Mon, 13 Nov 2017 16:50:29 -0500

> a given pricing model involves "price per packet" or "price per unit of

Now that I think about it that's a terminology error. Written before I
had the idea for billing methods being part of the spec.

There's no reason not to allow for packet or airtime billing at that
point. I will correct that. 

>   suggested encoding <Update metric=FFFF <pay metric=57 cost=94>>

This does provide more backwards compatibility since any version of
Babel will discard the update as infeasible regardless of 6126bis. So
long as we are limited to no more than a couple currency subtlv's per
update it should be an acceptable amount of duplicate information. 

> carry two parallel sets of updates.

ack, will do. 

> deserves defining precisely.

I see this as a billing advertising spec. The currency code is
interpreted by a billing program that does the actual payments and
follows it's own (as of yet unwritten) standard protocol. 

That being said maybe I removed too much when I decided to separate that
out. 

Both 1 and 2 are options. With 2 the entire path must agree on a
currency and you don't need to concern yourself with having scratch
money to pay suppliers. There's no reason to disallow (1) but then it's
on the billing implementation to potentially juggle currencies. 

For example lets say you don't go with the currency code advertised for
the path and instead add a few others. Then someone may pay you in
currency A where you have to pay the next hop in currency B. It's
possible you will run out of currency B and have to get more somewhere.
Hopefully using currency A that you just earned. Not to mention it's
possible to accidentally use an out of date exchange rate and end up
subsidizing the connection. 

Considering the added complexity on the part of the billing
implementation it may be better to simply ban (1).

Thanks for the feedback.

-- 
  Justin Kilpatrick
  [email-masked]