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 <maximede...@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
