Project

General

Profile

Task #5041

Redefine EndpointId as variant<ethernet::Address, ip::udp::endpoint>

Added by Teng Liang 7 months ago. Updated 3 days ago.

Status:
New
Priority:
Normal
Assignee:
Category:
Faces
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:

Description

The EndpointId is designed to identify the sender of a packet received from a multicast face, which is necessary info for unicast face creation. The current EndpointId is defined as uint64_t.

Potentially, the packet sender can be identified by Ethernet address (48-bit), UDP4 address (32+16=48 bits), and UDP6 address (128+16=142bits). Mapping UDP6 (142-bit) to EndpointId (64-bit) is challenging, so is the reverse mapping.

As discussed in 2019-11-25 NFD call, EndpointId is redefined as variant<ethernet::Address, ip::udp::endpoint>.


Related issues

Blocks NFD - Feature #4973: Self-learning: switch from multicast to unicast on Wi-Fi infrastructureIn ProgressTeng Liang

Actions
#1

Updated by Davide Pesavento 6 months ago

  • Category set to Faces
  • Start date deleted (10/31/2019)

Teng Liang wrote:

Mapping UDP6 (142-bit) to EndpointId (64-bit) is challenging, so is the reverse mapping.

Why is it challenging?

However, if EndpointId is redefined as string, then we can define EndpointId with the following format:

I really dislike using strings unless absolutely necessary. Also keep in mind that this means converting the remote address to a string, converting the port number to a string, and combining the two strings, all of this for every packet received on a multicast face.

If we need to change EndpointId type, I suggest using a variant.

#2

Updated by Teng Liang 6 months ago

Davide Pesavento wrote:

Teng Liang wrote:

Mapping UDP6 (142-bit) to EndpointId (64-bit) is challenging, so is the reverse mapping.

Why is it challenging?

I don't see a simple way to do reverse mapping.

However, if EndpointId is redefined as string, then we can define EndpointId with the following format:

I really dislike using strings unless absolutely necessary. Also keep in mind that this means converting the remote address to a string, converting the port number to a string, and combining the two strings, all of this for every packet received on a multicast face.

If we need to change EndpointId type, I suggest using a variant.

So how about variant<int64_t, int64_t*>, the former one is used for Ethernet and UDP4, and the latter one needs 3 64-bit for UDP6?

#3

Updated by Teng Liang 6 months ago

  • Description updated (diff)
#4

Updated by Davide Pesavento 9 days ago

  • Status changed from New to Rejected

I'm rejecting this. I strongly disagree with using/manipulating strings on a per-packet basis at such a low layer of the forwarder. Moreover, this is made (partially) obsolete by https://gerrit.named-data.net/c/NFD/+/6070 if I understand correctly.

#5

Updated by Alex Afanasyev 6 days ago

  • Subject changed from Redefine EndpointId as a string to Redefine EndpointId as variant<ethernet::Address, ip::udp::endpoint>
  • Description updated (diff)
  • Status changed from Rejected to New
  • Target version set to v0.8
#6

Updated by Alex Afanasyev 6 days ago

  • Blocks Feature #4973: Self-learning: switch from multicast to unicast on Wi-Fi infrastructure added
#7

Updated by Alex Afanasyev 6 days ago

  • Assignee set to Teng Liang
#8

Updated by Davide Pesavento 6 days ago

  • Description updated (diff)
#9

Updated by Teng Liang 6 days ago

In most cases, EndpointId has empty value. How about defining it as variant<std::monostate, ethernet::Address, ip::udp::endpoint> to make it default constructible without values?

#10

Updated by Davide Pesavento 6 days ago

Teng Liang wrote:

In most cases, EndpointId has empty value.

I suppose these cases are remnants from our failed attempt at introducing EndpointId in forwarding and strategies?

#11

Updated by Davide Pesavento 6 days ago

In any case, adding monostate is fine with me.

#12

Updated by Teng Liang 6 days ago

Davide Pesavento wrote:

Teng Liang wrote:

In most cases, EndpointId has empty value.

I suppose these cases are remnants from our failed attempt at introducing EndpointId in forwarding and strategies?

The current EndpointId is 0 when a Face is not multicast. What's the equivalent value when using variant?

#13

Updated by Alex Afanasyev 6 days ago

Why couldn't we have a valid endpoint for all faces, which can simply be interpreted as "remote" (almost equal to RemoveFaceUri, just programmatical, instead for human interpretation). Could this simplify things?..

#14

Updated by Davide Pesavento 6 days ago

Teng Liang wrote:

Davide Pesavento wrote:

Teng Liang wrote:

In most cases, EndpointId has empty value.

I suppose these cases are remnants from our failed attempt at introducing EndpointId in forwarding and strategies?

The current EndpointId is 0 when a Face is not multicast. What's the equivalent value when using variant?

For non-multicast faces, the EndpointId value is meaningless and should never be used. So you could literally use any invalid address, it doesn't matter. But as I said, monostate is fine and makes the "invalid case" more explicit.

#15

Updated by Davide Pesavento 6 days ago

Alex Afanasyev wrote:

Why couldn't we have a valid endpoint for all faces, which can simply be interpreted as "remote" (almost equal to RemoveFaceUri, just programmatical, instead for human interpretation). Could this simplify things?..

We could do that, given that the information is available at the socket layer. But it would be kind of useless, as the rest of NFD doesn't use that information. So I'd leave this extension for later, if we ever need it.

#16

Updated by Alex Afanasyev 6 days ago

Agreed

Also available in: Atom PDF