LSD0004 call for reviews

[Maxime Devos]

> Block Storage
>     The Block Storage component is used to persist and manage data by
> nodes. It includes logic for quotas, caching stragegies and data
> validation.

stagegies -> strategies

> Responsible Peer:
>     The peer N that is responsible for a specific resource K, as
> defined by the SelectClosestNode(K, N) algorithm (see Section 7.

missing closing parenthesis

>  In order to achieve O(log n) routing performance

> 0: Demultiplex-Everywhere
    indicates that each node along the way should process the request.

What's the advantage of not doing this by default?  And what is
Demultiplex-Everywhere useful for?

> 3-15: Reserved
>     For future use.

What should a peer do when it encounters one of these?
Set it to zero? Ignore the unknown flags? Drop the message?
Disconnect from the peer that sent it?

> EXPIRATION
>     denotes the absolute 64-bit expiration date of the content. The
> value specified is microseconds since midnight (0 hour), January 1,
> 1970, but must be a multiple of one million (so that it can be
> represented in seconds in a HELLO URL). Stored in network byte order.

What should a peer do when the expiration isn't a multiple of one
million?  Round it, drop it?  What's the problem with not exactly
being representable in a HELLO URL when it's not exactly a multiple
of one million, wouldn't an approximation do?

> ADDRESSES
>     A sequence of exactly URL_CTR 0-terminated URIs in UTF-8 encoding
> representing addresses of this peer. Each URI must begin with a non-
> empty URI schema terminated by "://" and followed by some non-empty
> Underlay-specific address encoding.

If I have two addresses FOO and BAR, do they need to be encoded as
FOO<0 byte>BAR or FOO<0 byte>BAR<0 byte>?  What should the peer do
if it encounters superfluous 0 bytes: FOO<0 byte><0 byte>?  Is a
sequence of zero URLs acceptable?  If a sequence of zero URLs is
acceptable, does it need to be encoded as <0 byte> or <nothing>?

What should happen if the field is bogus?  Why zero-encoding and not
length-prefixed?  Length-prefixed is IMHO easier to parse, with less
chance of going out-of-bounds.

> PATH_LEN
>    is a 16-bit number indicating the length of the PUT path recorded
>    in PUTPATH. As PUTPATH is optional, this value may be zero. In
>    network byte order.

Is this optional even when Record-Route is specified?  Is this 'length'
the number of path elements, or the byte size of all the path elements?

> HOPCOUNT
>     is a 16-bit number indicating how many hops this message has
> traversed to far. In network byte order.

Wouldn't PATH_LEN = HOPCOUNT when Record-Route is requested?  What's
the difference?

> EXPIRATION
>     denotes the absolute 64-bit expiration date of the content. In  
>  microseconds since midnight (0 hour), January 1, 1970 in network
> byte order.

Do leap seconds count? How about time zones?

> REPL_LVL
>     is a 16-bit number indicating the desired replication level of
>  the data. In network byte order.

What about its bounds?  The GNUnet DHT service imposes some bounds,
e.g. it requires it to be >0 and <=10 IIRC.


> BLOCK
>     the variable-length block payload. The contents are determined by
>  the BTYPE field.

How do I know the length of this payload? 

>  The EXPIRATION field is evaluated. If the message is expired, it
>  MUST be discarded.

How can I know if a message is expired, when clocks aren't perfect?
Will an approximation be sufficient?

> If the local node is the closest node (cf. IsClosestNode(N, Key)) or
> the DemultiplexEverywhere options flag ist set, the message MUST be
> stored locally in the block storage.

ist set --> is set

> The implementation MAY forward to fewer or no peers in order to
> handle resource constraints such as bandwidth

So if REPL_LEVEL is 65535, the peer doesn't actually have to forward it
to thousands of peers?  Peers are responsible for stopping
amplification attacks?

Also, wouldn't the number of peers grow exponentially as the message
passes through the network?  The first peers passes it to k other
peers, each peer passes it to another k peers ..., then at step n, 
∑(i=1..n)k^i = ϴ(k^n) have been contacted (assuming no duplicate
peers).

> XQUERY    the variable-length extended query. Optional.

How do I now if this is present?  Is it absent whenever XQ_SIZE=0?

> RESULT_BF
>     the variable-length result bloomfilter

How do I know its length?

> OPTIONS
>     is a 16-bit options field (see below).

What if there are unrecognised options?

> MTYPE
>    is the 16-bit message type. This type can be one of the DHT
>  message types but for put messages it must be set to the value 148
> in network byte order.

Does that mean that no DHT message type has the value 148?

>  9.1. Block Processing 

What about an OK_UNKNOWN result, if it is unknown whether the response
matches the key?  For example, for Guix, we could use the DHT to map
store item names /gnu/store/....-foo-1.0 to corresponding GNUnet FS
URIs.  Assuming reproducibility, there's only a single FS URI for each
store item name, so we can locally keep a database from store item
names to GNUnet FS URIs, and reject the FS URI when it doesn't match
the FS URI in the local database.  But we can neither reject nor accept
it when the local database does not have any entry for the store item
name ...

> DeriveBlockKey(Block) -> Key
>    is used to synthesize the block key from the block payload and
>  metadata. It is used as part of FIND-node message processing.

That seems sometimes impossible, you can't map a FS URI to the Guix
store name since multiple store items can have the same contents.

>  The ADDRESSES part of the HELLO indicate endpoints which can be used
> by the Underlay in order to establish a connection with the node
> identified by Peer-ID. An example of an addressing scheme used
> throughout this document is "ip+tcp", which refers to a standard
> TCP/IP socket connection. The "hier"-part of the URI must provide a
> suitable address for the given addressing scheme. The following is a
> non-normative example of address strings:
> 
> ip+udp://1.2.3.4:6789 \
> gnunet+tcp://12.3.4.5/ \

So it doesn't have to be a registered URI Scheme, it only has to look
like an URI?  Does GANA need to keep a registry for addressing schemes?

How are IPv6 addresses represented?  With []?
Also, what about link-local addresses and addresses for local IPv4
networks, which cannot reasonably be spread?

> GANA [GANA] is requested to create a "DHT Block Types" registry. The
> registry shall record for each entry:

Does 148 and 157 need to be reserved?

>  GANA is requested to amend the "GNUnet Signature Purpose" registry
> as follows:
> 
> Purpose | Name            | References | Description
> --------+-----------------+------------+---------------

Looks empty.

> An implementation MAY limit the number the number of neighbours it
> stores is any k-bucket of the routing table.
> However, the lower bound MUST be adhered to

What if the peer only is just connecting to the network?  Initially,
it doesn't know any neighbours yet (or very few), so it cannot add them
to the k-buckets yet, and hence the lower bound (assuming it isn't
zero) would necessarily be violated, right?

Also, about expirations: if I know that the type-key-value mapping is
good forever, can I just set it to 18446744073709551615, or would this
be problematic somehow?

Greetings,
Maxime.

signature.asc
Description: This is a digitally signed message part