Subject: Re: [Ipoverib] consensus call on EtherType, min MTU and DHCPv4

From: Ajoy C Siddabathuni <[email-masked]>
Date: Mon, 15 Apr 2002 15:52:39 -0700 (PDT)

>It takes another 4 bytes and provides no new information. The issues
>you indicate above are equally addressed by a 'type' field.

Ofcourse it provides no new information - if you are running IPoIB
in vacum. It is much cleaner than putting a 4 byte header with reserved
fields. Also expect (in a few years) that there will be multi-protocol 
routers that will be sitting at the edges of an IB-Ethernet-osi-apple-network.
They would definetly like to handle packets in a std way - especially when
cp'ing pkts from one kind of "link" to another. They dont need to handle
cases such as - "oh by the way, if this link was an IPoIB link..I needed to
strip the top 4bytes...and not interpret the next 16 bits before I look at
the eth-type".

>
>'No header case' is disallowed as per WG consensus. Otherwise, the
>4-byte ethertype field is equally viable as the 8 byte LLC/SNAP field.
>It has the advantage of being 4 bytes smaller.

I would'nt consider "4 bytes smaller" as an advantage. Especially if you are
working with IB header lengths upto 68 bytes. And then if you are working with
TCP/IPv4/v6 add upto 60+.

>
>How about RFC2734 ? There is nothing standard about this.
Well - time to learn from another's mistakes.

Here is my summary -

 - Having no-header at all will give you alignment. No ethtype to mux on.
   But you could have always figured out all IP'ish types from the IP-hdrtype
   field.
 
 - Having 4byte "non-std" header will also give you alignment. Gives you
   all the info you need. But yes, there are certain non-std elements in
   the header that implementations would have to be aware of  - especially
   if they were porting an existing stack.
   
 - Having 8byte std-header will be standards conforming for future multi-prot-
   col enviroments. Ofcourse, retains alignment.

~Ajoy

>> 
>> Frame formats -
>> 
>> a) If LLC/SNAP was used then you automatically get a 32bit-word alignment
>>    for the IP-Datagram.
>>    
>>    The frame would look something like --
>>    
>>    LRH (8bytes)
>>    GRH (40 bytes)*
>>    BTH (12 bytes)
>>    DETH (8 bytes)
>>                LLC       OUI     EthType
>>    LLC/SNAP <AA-AA-03><00-00-00><xx-xx>   (8bytes)
>>    IPv4/IPv6 Datagram
>>    ICRC
>>    VCRC
>>    
>> b) Embedding just the  ethtype - the frame would look like -- also gives
>>    you the alignment - but is a non-std way of doing things (with reserved
>>    fields etc in the format).
>> 
>>    LRH (8bytes)
>>    GRH (40 bytes)*
>>    BTH (12 bytes)
>>    DETH (8 bytes)
>>    
>>     Rsvd   EthType
>>    <??-??><xx-xx>  (4bytes)
>>    IPv4/IPv6 Datagram
>>    ICRC
>>    VCRC
>> ----
>> 
>> My opinion on this is that if EthType is ever supported, it should be
>> supported using the std mechanism (a) to be consistent with how other
>> IPoverXXX protocols have been defined in the past. (See RFCs -ATM: 2225,
>> 1577, 1483 SMDS:1209 FR:1294)
>
>How about RFC2734 ? There is nothing standard about this.
>
>[ As another example one can even use a 2 byte header if it works out
>for the hardware -i.e. if one can DMA to a 2 byte boundary, the IP
>header will land at a 4 byte boundary. ]
>
>Vivek
>
>> 
>> If the WG feels that in the foreseeable future, only IP will ever be
>> supported, then yes there is no need for the Ethtype - ie. leave it alone,
>> you can still get the IP datagram 32bit aligned right after DETH. On the
>> other hand, if the WG feels that we do it the way our ancestors have done it
>> there is enough argument already in place for supporting llc/snap hdrs.
>> 
>> ~Ajoy
>> 
>> 
>> >X-Sender: [email-masked]
>> >Date: Mon, 15 Apr 2002 10:20:49 -0700
>> >To: Yaron Haviv <[email-masked]>, "'H.K. Jerry Chu'" 
>> <[email-masked]>, "[email-masked]'" <[email-masked]>, 
>> "[email-masked]'" <[email-masked]>
>> >From: Michael Krause <[email-masked]>
>> >Subject: RE: [Ipoverib] consensus call on EtherType, min MTU and DHCPv4
>> >Mime-Version: 1.0
>> >X-Mailman-Version: 1.0
>> >List-Id: IP over InfiniBand WG Discussion List <ipoverib.ietf.org>
>> >X-BeenThere: [email-masked]
>> >
>> >At 10:31 AM 4/14/2002 +0200, Yaron Haviv wrote:
>> >>Jerry,
>> >>
>> >>We must stop expending the definition somewhere so we get the spec out
>> >>This is IPoIB we are talking about, there is no need for LLC/SNAP, and we
>> >>just need the Ethertype
>> >
>> >The consensus is that people want to have the full range of Ethertype 
>> >values supported.  As such, this needs to be specified independent of the 
>> >IP over IB specification so that everyone may use these values without 
>> >requiring them to implement IP over IB.
>> >
>> >Mike
>> >
>> >
>> >_______________________________________________
>> >IPoverIB mailing list
>> >[email-masked]
>> >https://www1.ietf.org/mailman/listinfo/ipoverib
>> 
>> 
>> _______________________________________________
>> IPoverIB mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/ipoverib
>> 
>
>
>-- 
>Vivek Kashyap
>Linux Technology Center, IBM
>[email-masked] 
>[email-masked] 
>503 578 3422 (o)

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

---

From: Michael Krause <[email-masked]>
Date: Mon, 15 Apr 2002 16:22:50 -0700

>strip the top 4bytes...and not interpret the next 16 bits before I look at

Amazing to see the charter of this workgroup be so permuted to solve all 
multi-protocol problems that we now should be encumbered with even more 
overhead.  Small packet protocol efficiency is absurd when you consider 
there is now at least 2-3x protocol overhead just to move a TCP SYN/FIN/ACK 
packet through the fabric.

>TCP/IPv4/v6 add upto 60+.

This translates into 1-2 cache lines of overhead per packet moved through 
the fabric (function of the cache line size). In general, we'd like to not 
touch cache lines whenever possible since this impacts performance.

>    col enviroments. Ofcourse, retains alignment.

Continuing along this line of specification development makes one wonder 
how much performance people were expecting to get out of their solutions?

Going back to the original BOF when someone questioned why don't you just 
add in Ethernet TCAs and simplify the entire IP router problem by running 
something like RNDIS or an equivalent open solution and many noted this was 
a reasonable approach.  Why that same approach cannot be used now using a 
UD instead of a connected transport service to solve the perceived 
scalability problem is no longer viewed as reasonable makes little 
sense.  Anyone added up the cost of building / deploying these 
multiprotocol routers to determine whether all of this added complexity 
(IMO, unnecessary especially w.r.t. multicast and multi-protocol approaches 
to date) provides a reasonable cost / benefit trade-off?

Mike