Re: LSD0004 call for reviews

[Schanzenbach, Martin]

Thank you very much Maxime. I will look into the feedback this week.

Just a side note: LSD0004 (the DHT) ist still in a very early, rough state.
LSD0001 (GNS) is what is currently in the final stages and needs some fresh 
eyes before
submission, if you are interested. :)

Anyway. As soon as I have the time I will address the feedback below.

Thanks!
Martin

> On 7. Feb 2022, at 10:39, Maxime Devos <maximedevos@telenet.be> wrote:
> 
>> 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: Message signed with OpenPGP