Subject: RE: [Ipoverib] IPoIB architecture/encapsulation (EtherType or not)

From: "H.K. Jerry Chu" <[email-masked]>
Date: Sun, 13 Jan 2002 22:31:09 -0800 (PST)

>From: "Bill Strahm" <[email-masked]>
...
<snip>

>I understand that QPN are a scarce resource, but attaching multiple
>protocols on top of a single QPN and having an upper layer demux does not
>seem like the answer, if I do this, then I do not know what memory address
>to deliver the packets to, so I might incur a copy... At a minimum I incur a
>page flip.

Even dedicating one QP per layer-3 protocol won't give you zero-copy.
To target per-session memory, you'll need one QP per session, e.g. TCP
connection.

Almost a year ago in my first IPoIB proposal to IBTA/LWG (predating
IETF/WG), I had a "skip EtherType" flag in the IPoIB MAC addr.
Each node can decide whether it wants EtherType to be included in
all the unicast pkts destined for it. E.g. if a node has abundant
QPs, it can dedicate one for each EtherType and tells everyone else
not to embed one in payload. But later I felt it was such a frivilous 
optimization to be worth carried forward...

>
>WG Chair hat on ...
>My understanding is that we have 2 major points to consider before we can
>get to WG last call on the Encapsulation draft they are
>1) Use of Ethertype, or not in the encapsulation
>2) What to do about IP subnets crossing IB subnets, allow, architect for,
>don't consider

Actually I think the number one question to be answered is what
consistutes an IPoIB link layer address.

Jerry

>
>I know that there are some link issues that Jerry has brought up, hopefully
>his draft on the topic will come up early next week and people can tell me
>what there opinions are.
>
>The goal is to have a draft that is VERY close to WG Last call for the
>Minnesota IETF, so we can tweak it and ask for Last Call after the meeting.
>Please comment on these topics and I will try to direct the conversation,
>and see if we have an answer.
>
>Bill
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]On Behalf
>Of Arvind Murching
>Sent: Sunday, January 13, 2002 11:12 AM
>To: H.K. Jerry Chu; [email-masked]
>Subject: RE: [Ipoverib] IPoIB architecture/encapsulation (EtherType or
>not)
>
>
>FWIW, other IP over FOO RFCs do take care to allow protocols other than
>IP to share the link layer connection, typically using an EtherType.
>
>-----Original Message-----
>From: H.K. Jerry Chu [mailto:[email-masked]]
>Sent: Saturday, January 12, 2002 4:52 PM
>To: [email-masked]
>Subject: Re: [Ipoverib] IPoIB architecture/encapsulation
>
>
>Sorry I am late to the party (was stuck on something else most of Dec.),
>but like to make some comments regarding EtherType.
>
>While I don't buy the performance arguement, I sympathize with Vivek on
>his feeling toward EtherType. Architecturally it is ugly to force one
>into the payload. The right approach would have the framing layer
>carrying a field identifying the type of data being encapsulated. But
>BTH wasn't designed for encapusulation purpose. That is supposed to be
>the job and the only purpose of raw datagrams.
>Unfortunately due to various reasons the latter has been considered by
>many as not fit for the job of IPoIB encapsulation.
>
>Aside from the architectural correctness, I only see two valid concerns
>against not including EtherType:
>
>1. Compatibility issue - how many existing stack implementations expect
>EtherType, or part of framing header to be present in the datastream?
>Although the driver can always fabricate a pseudo header if one is
>needed but is missing, it may incur some performance penalty since it
>won't be in-line.
>
>2. Not including Ethertype forbids one from sharing the same QP with
>other protocols outside of IPv4/ARP/IPv6. Is this a legitimate concern?
>Note that this concerns only applies unicast. For multicast, by
>embedding a special IPoIB signature in MGIDs for IPv4/ARP/IPv6 use only,
>demuxing can be based on MGID so sharing QPs won't be an issue.
>
>Before the two questions are fully understood, I'm leaning slightly
>toward including the EtherType, just to be on the safe side.
>
>Jerry
>
><snip>
>
>
>_______________________________________________
>IPoverIB mailing list
>[email-masked]
>http://www.ietf.org/mailman/listinfo/ipoverib
>

_______________________________________________
IPoverIB mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ipoverib