Subject: RE: [Ipoverib] recharter consideration

From: "Glaser, Steve" <[email-masked]>
Date: Fri, 6 Sep 2002 15:32:00 -0400

The only reason I can think of for doing this is to overcome a Path MTU
limitation.

UD is limited to the PMTU of IB (i.e. it could be 256 bytes and is never
more than 4K bytes so ~8K byte jumbo Ethernet packets will never fit).

256 IP packets are doable, but are kind of a pain and are a big software
overhead.  Note that IPV6 deleted IP level fragmentation so small IPV6
packets are also visible at the TCP and UDP levels.

There may be good reasons to run an IB network with small MTU sizes
(improved latency for high priority packets for instance).

Running IP over non-UD could be similar to running IP over ATM Virtual
Circuits. A "connection" is set up and torn down automagically when needed
and any "reliability" is only used to allow bigger messages to be fragmented
into a sequence of smaller messages. Yes the IB retries are done in hardware
and are thus transparent to TCP, but that's gravy and is not the main reason
for going reliable.

Steve Glaser
Paceline Systems

-----Original Message-----
From: Caitlin Bestler [mailto:[email-masked]]
Sent: Friday, September 06, 2002 2:51 PM
To: Thomas Narten
Cc: Vivek Kashyap; H.K. Jerry Chu; [email-masked]; [email-masked];
[email-masked]
Subject: Re: [Ipoverib] recharter consideration 

On 9/6/02, Thomas Narten wrote:

>
>> 1) encapsulating IP datagrams using a non-UD transport
(e.g.
>> UC, RC)
>> question - scope is not clear
>> <VK> What is meant by 'scope' in this regard? Does
>> draft-kashyap-ipoib-advanced-capabilities-00.txt provide
>> some of the answers?
>> <VK>
>
>There are many non-UD transport modes. Is the proposal to
>define an ecapsulation for each of other other modes? Or
>Just one (and if so, which one)?
>

What would the purpose of supporting other transport modes
with a line protocol be?

Supporting raw IP datagrams over UD has valuable transition
benefits. However, if an application has a reliable stream,
or reliable datagram view of their communication link they
should simply use those modes. Providing compatability with
pre-IB networks is best done by the local interface. It is
an API issue, not a wire protocol issue.

Exactly emulating the behaviour of a TCP connection when it
is tunneled within an RC connection would be pointless. TCP
rides over an  unreliable packeted transport. Typically the
goal will be to simply relay messages or streams, without
all the nuances imposed by TCP's implementation. In that
case the wire protocols are already defined: InfiniBand
itself or Sockets Direct Protocol. When the goal is
compatability with non-IB but RDMA protocols the Direct
Access Transport Collaborative has defined the kDAPL and
uDAPL APIs.

What problem would be solved by 'supporting' other transport
modes that is not *better* addressed elsewhere?

Caitlin Bestler
http://asomi.com/CaitlinBestler/
 
_______________________________________________
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: Caitlin Bestler <[email-masked]>
Date: Fri, 6 Sep 2002 15:17:41 -0500

On 9/6/02, Glaser, Steve wrote:

>The only reason I can think of for doing this is to
>overcome a Path MTU limitation.
>

Why would RC be used, rather than reliable multi-packet
transation protocol used for large management datagrams
(section 15.3)?
_______________________________________________
IPoverIB mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipoverib

---

From: Yaron Haviv <[email-masked]>
Date: Sun, 08 Sep 2002 22:33:37 +0300

Other reasons for RC are the ability to use RC based mechanisms such as:
Automatic path migration (APM)
ECN's
e-2-e flow control
etc..

Which IPoIB can greatly benefit from

Yaron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Glaser, Steve
Sent: Friday, September 06, 2002 10:32 PM
To: 'Caitlin Bestler'; Thomas Narten
Cc: Vivek Kashyap; H.K. Jerry Chu; [email-masked]; [email-masked];
[email-masked]
Subject: RE: [Ipoverib] recharter consideration

Steve Glaser
Paceline Systems

-----Original Message-----
From: Caitlin Bestler [mailto:[email-masked]]
Sent: Friday, September 06, 2002 2:51 PM
To: Thomas Narten
Cc: Vivek Kashyap; H.K. Jerry Chu; [email-masked]; [email-masked];
[email-masked]

(e.g.

Caitlin Bestler