Subject: RE: [ipoverib] moving forward with the open Issues - end node

From: "Grun, Paul" <[email-masked]>
Date: Tue, 26 Feb 2002 08:29:17 -0800

Hey, who am I to disagree?
-paul

-----Original Message-----
From: Roger Ronald [mailto:[email-masked]]
Sent: Tuesday, February 26, 2002 6:26 AM
To: H.K. Jerry Chu; [email-masked]; [email-masked];
[email-masked]
Subject: Re: [ipoverib] moving forward with the open Issues - end node

I heartily concur with these comments. Most of the 1st generation silicon
out there does not handle 2K UD (at least not very well). While I don't
have any great vested interest in any existing hardware (beyond the
100 or so cards we use internally), I can't see why the use of a 
smaller MTU is so offensive. Sure, performance will be much better
with a larger MTU....but, in my book, performance is what comes after
interoperability. Once you have everyone interoperating, performance
enhancements and claims will naturally follow. 

RR
----- Original Message ----- 
From: "H.K. Jerry Chu" <[email-masked]>
To: <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Tuesday, February 26, 2002 2:23 AM
Subject: RE: [ipoverib] moving forward with the open Issues - end node

> I fail to see the need for specifying a "default" MTU for IPoIB, or
> limiting the MTU choices to >= 2048. Can someone present a case for
> these arguments?
> 
> IPoIB must always go through some link setup procedure in order to
> have a multicast group for broadcast purpose. THe link MTU size will
> be chosen then. What is the value of designating a "default" MTU then?
> Note that both drafts mention the benefit of having a large MTU, but
> leave the final choice at the hand of the adminstrator.
> 
> If the concern of allowing devices of smaller MTU is the difficulty
> it may present for IB <-> Ethernet bridging or routing, router link
> MTU option and PMTU should alleviate the headache from the MTU
> discrepancy between the two, right?
> 
> Jerry
> 
> >Date: Sat, 23 Feb 2002 20:50:09 -0800
> >From: "Sukanta Ganguly" <[email-masked]>
> >To: "Grun, Paul" <[email-masked]>, [email-masked]
> >Subject: RE: [ipoverib] moving forward with the open Issues - end node
> >Mime-Version: 1.0
> >Content-Transfer-Encoding: 8bit
> >X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org
id 
> XAA14313
> >X-Mailman-Version: 1.0
> >List-Id: IP over InfiniBand WG Discussion List <ipoverib.ietf.org>
> >X-BeenThere: [email-masked]
> >
> >I thought so too. I was beaten down to a pulp by Bill on this one. I do
agree 
> with him after understanding his reasonings.
> >
> >SG
> >
> >*********** REPLY SEPARATOR  ***********
> >
> >On 2/7/2002 at 4:15 PM Grun, Paul wrote:
> >
> >>I thought that there was consensus early on that we would assume that an
> >>IBA
> >>fabric supporting IPoverIB would provide a minimum MTU of 2K bytes?
Didn't
> >>we agree not to pursue the smaller MTUs?
> >>-paul
> >>
> >>> -----Original Message-----
> >>> From: Vivek Kashyap [mailto:[email-masked]]
> >>> Sent: Thursday, February 07, 2002 4:12 PM
> >>> To: [email-masked]
> >>> Cc: [email-masked]
> >>> Subject: Re: [ipoverib] moving forward with the open Issues - end node
> >>> 
> >>> 
> >>> > 
> >>> > Yaron, 
> >>> > Thanks for your response.
> >>> > 
> >>> > BTW, I think "what IPoIB-default-MTU should be" is an open issue.
> >>> > right ?
> >>> 
> >>> Akihiko,
> >>> 
> >>>         We don't have a default MTU; the administrator is free to set
> >>>         any of the 5 possible values (256,512,1024,2048,4096 bytes)
> >>>         based on the capacity of the CAs/switches in the subnet.
> >>> 
> >>>         In general using a minimum link MTU (and hence choosing the
> >>>         'right' equipment) of 2048 bytes makes sense. This link MTU
> >>>         allows for the IP MTU to be set to 1500 (ethernet
> >>>         internetworking) or 1280 (IPv6 minimum) if so desired. The
> >>>         smaller MTUs are not optimal.
> >>> 
> >>>         No default though except in terms of :
> >>> 
> >>>         If No-ethertype in payload
> >>> 
> >>> IP MTU = IPoIB link MTU 
> >>> 
> >>> else
> >>> IP MTU = IPoIB link MTU - sizeof('ethertype')
> >>> 
> >>> 
> >>> 
> >>> Vivek
> >>> 
> >>> > 
> >>> > >-----Original Message-----
> >>> > >From: [email-masked] 
> >>[mailto:[email-masked]]On Behalf Of
> >>> >[email-masked]
> >>> >Sent: Friday, February 01, 2002 5:20 AM
> >>> >To: [email-masked]
> >>> >Cc: 'Michael Krause'; [email-masked]
> >>> >Subject: Re: [ipoverib] moving forward with the open Issues - end
node
> >>> >
> >>> >>Date: Thu, 31 Jan 2002 20:36:34 +0200
> >>> >>From: Yaron Haviv <[email-masked]>
> >>> >>Subject: RE: [ipoverib] moving forward with the open Issues - end
node
> >>> >>Mike,
> >>> >>
> >>> >>If you look at my last email from yesterday
> >>> >>I acknowledge that, and say that we need to look into in the future
and
> >>not
> >>> >>in this RFC, so this issue isn't open anymore
> >>> >>The only open issue currently is the Ethertype field
> >>> >>
> >>> >>Yaron
> >>> >
> >>> >Please let me confirm this default MTU issue.
> >>> >
> >>> >If Ethertype is not in payload, default IP-MTU is 2048.
> >>> >Otherwise (=if Ethertype is in payload),
> >>> > default IP-MTU is not 2048.
> >>> >It's 2048 - EterhType field length. (4? probably not 2)
> >>> >
> >>
> >>_______________________________________________
> >>IPoverIB mailing list
> >>[email-masked]
> >>https://www1.ietf.org/mailman/listinfo/ipoverib
> >>
> >>_______________________________________________
> >>IPoverIB mailing list
> >>[email-masked]
> >>https://www1.ietf.org/mailman/listinfo/ipoverib
> >
> >
> >
> >
> >_______________________________________________
> >IPoverIB mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/ipoverib
> 
> 
> _______________________________________________
> IPoverIB mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ipoverib
> 
> 

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

---

From: Joe Pelissier <[email-masked]>
Date: Tue, 26 Feb 2002 08:53:36 -0800

Unfortunately, there is an unavoidable issue with IPv6.  The standard (RFC2460)
on page 22 states:

"IPv6 requires that every link in the internet have an MTU of 1280 octets or
greater.  On any link that cannot convey a 1280-octet packet in one piece,
link-specific fragmentation and reassembly must be provided at a layer below
IPv6."

Since IB does not specify a link specific fragmentation and reassembly for UD,
there are two choices:

1) Specify a link specific fragmentation and reassembly of UD in ip over ib.

2) Don't specify one which implies that IPv6 only operates over IB networks with
>= 2k mtu.

(btw - the specification for IPv4 is 68 bytes; however, 576 bytes works better
to handle all of the ICMP messages without fragmentation, see RFC 760 page 22.
Anyway, this does not seem to be an issue for IPv4).

My preference is to keep it simple and go with #2.

Regards,
Joe Pelissier
[email-masked]

---

From: "Roger Ronald" <[email-masked]>
Date: Tue, 26 Feb 2002 12:48:02 -0600

I concur. IPv4 should run on everything that supports 68 bytes or more.
IPv6 should only run on media that offer an effective MTU of 1280 
bytes or more. 

I see no reason to complicate the general IP over IB case by
spec'ing IPv6 over IB with MTU challenged links.

RR