Editorial: rename source/destination CID to local/remote CID

[djc]

I'm relatively new to the QUIC WG; I started an implementation from scratch this month. I hope it's okay to raise this issue here and it has not been bikeshedded to death earlier.

On reading the spec, I've found the notion of source connection ID and destination CID somewhat confusing and hard to reason about. On further reflection, I believe that it would be beneficial to respectively rename them as "local CID" and "remote CID" instead.

Here's my rationalization: in terms of graph theory, it seems to me that "source" and "destination" refer to vertex properties of (directed) edges. It seems that the fields in question, on the other hand, are meant to identify edges from the perspective of the vertices. As such, the "remote" CID is how the remote peer refers to the shared connection, while the "local" CID is how the local peer refers to it.

[MikeBishop]

I can understand the confusion, and opening an issue is certainly an appropriate way to raise a suggestion on the spec. Welcome!

The issue here is that the packet is sent from one node to another -- it's part of a directed edge, if you want to use that terminology. So "source" and "destination" are properties of that edge, and are true on both ends -- the source of an outbound packet is you, and the destination of an inbound packet is you.

However, "local" and "remote" seems more prone to confusion, since the "remote" CID will be my local CID on packets I receive.

[djc]

@MikeBishop that's a good counterpoint. I suppose the fact that packets actually traverse the edge does make the edge's perspective important.

I think part of my problem was thinking about the state I have to keep for an endpoint, for which I guess "local" and "remote" could work better, but for packets "source" and "destination" definitely make more sense to me now.

[LPardue]

Welcome!

Nomenclature is hard. Client and server are typical phrases which work ok, but for my use cases "sender" and "receiver" work better.

It's all a compromise that needs to meet the generality of user expectation!

[dtikhonov]

How about "peer?" Works for sockets.

[djc]

I really like the suggestion of "sender" and "receiver" at least in the context of a packet. I think that might be because the references is more directly from the packet itself to the peers who handle the packet, rather than the more indirect connection through the edge to its source and destination.

As for "peer", that doesn't distinguish between the two peers participating in the connection, so I presume it would not be very helpful.

[martinthomson]

I chose "source" and "destination" to be congruent with source and destination IP addresses. The point being that the connection ID serves an identical purpose.