Re: [Xen-devel] [PATCH 5/5] xen: Add V4V implementation

[Jean Guyader <jean.guyader@xxxxxxxxx>]

On 13 August 2012 10:38, Tim Deegan <tim@xxxxxxx> wrote:
> At 17:51 +0100 on 10 Aug (1344621069), Jean Guyader wrote:
>> On 09/08 11:38, Tim Deegan wrote:
>> > Hi,
>> >
>> > This looks pretty good; I think you've addressed almost all my comments
>> > except for one, which is really a design decision raether than an
>> > implementation one.  As I said last time:
>> >
>> > ] And what about protocol?  Protocol seems to have ended up as a bit of a
>> > ] second-class citizen in v4v; it's defined, and indeed required, but not
>> > ] used for routing or for acccess control, so all traffic to a given port
>> > ] _on every protocol_ ends up on the same ring.
>> > ]
>> > ] This is the inverse of the TCP/IP namespace that you're copying, where
>> > ] protocol demux happens before port demux.  And I think it will bite
>> > ] someone if you ever, for example, want to send ICMP or GRE over a v4v
>> > ] channel.
>> >
>>
>> The protocol field is used to inform about the type a message on the ring.
>>
>> Right now we use two protocols in our linux driver: V4V_PROTO_DGRAM and
>> V4V_PROTO_STREAM. In the future that could probably be extended to new 
>> protocol
>> like V4V_PROTO_ICMP for instance.
>>
>> The demultiplexing will happens at the other end, the driver can look at the
>> message and decide what to do with it based on the protocol field.
>
> Yes, I understand all that - what I'm saying is that it seems like a
> design flaw to me.  The namespace in V4V, as proposed, looks like this:
>
>  Protocol
>  Port
>  Domain
>

Protocol isn't part of the namespace - I think that's
where the confusion arises. The namespace is exclusively
Port/Domain. Protocol is there to describe the content of
_a particular message_ in the ring. It is included in the
hypercalls (rather than, say, being the first n bytes of
all messages) to force all senders to use it.

The other key point here is confusion as to what V4V is.
V4V is _not_ a tcp or udp clone. V4V exists to provide
a mechanism to transfer messages (which are arbitary
strings of bytes, labeled with a "protocol") between
endpoitns (labeled by a domain and port).

An example use of this facility uses two v4v rings to
implement something which looks quite like TCP. In this
case to distinguish TCP-a-like messages from other
such messages that may or may not be present on the ring,
the messages are labeled with a protocol field that
indicates what upper layer should handle these messages.

One can easily immagine circumstances where messages of
many different protocols are present on the ring. An
obvious example might be a message type which implemented
some sort of flow control, that quenced or started
transmission on a partner ring, regardless of what other
messages were being sent on the rings.

> and it would be more sensible to do (like the IP stack):
>
>  Port
>  Protocol
>  Domain.
>
> Or at the very least the protocol should be made part of the endpoint
> address, and not just part of the packet header.  As it stands:
>
>  - The handlers for port X in _all_ protocols _have_ to share a
>    ring.  That seems kind of plausible because the IANA port assignments
>    never give the same port number to different services on TCP and UDP,
>    but will it make sense for every new protocol?  Is it sensible to
>    require, say, an L2TP service to make its connection IDs not clash
>    with V4V_PROTO_DGRAM and V4V_PROTO_STREAM users?
>
>    It may not even make sense in existing protocols.  It's common enough
>    for DNS servers to use different ACLs (and indeed different servers)
>    for TCP and UDP.
>

V4V isn't IP, but you raise a valid point. We should
define two ranges of 16 bit V4V port numbers one which
is "well known" for the use of TCP encapsulation, and
one which is "well known" for the use of UDP
encapsulation.  That then makes the concept that you
think that protocol should be, be part of the
endpoint address, and it leaves the thing I misleadingly
called "protocol" free to be the message type label.

>  - Relatedly, every protocol _has_ to have port numbers.  How would you
>    register an ICMP listener, for example?  You'd have to do something
>    gross like declare a particular port to be the ICMP port so that you
>    could demux it, or indeed send it in the first place.
>
> You say:
>
>> The demultiplexing will happens at the other end, the driver can look at the
>> message and decide what to do with it based on the protocol field.
>
> I'm willing to accept that argument, but only if we extend it to ports
> too, get rid of all the namespace and ACL code in Xen and leave each
> domain with a single RX ring that the (single) guest driver must demux. :P
>

Cheers,
Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel