Subject: Re: [Ipoverib] recharter consideration

From: "Vivek Kashyap" <[email-masked]>
Date: Wed, 4 Sep 2002 17:03:02 -0700

My response between <VK> below.

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>

2) demux IP datagrams over multiple QPs

issue - dubious benefit; it may introduce routing and session
establishment problems?

<VK> To discuss this issue better I would like to know what are the
routing/session establishment problems that have been brought forward?
<VK>

(Two opposed this item in f2f meeting.)

<VK> How many were in the room? <VK>

3) other client capability, e.g. SDP

issue - non-IP therefore out of scope

<VK> That is fine in my opinion. <VK>

4) skipping TCP/UDP checksum when running over RC/UC.

issues - serious concern from many. difficult to ensure end2end
property. could be made to work in a limited set of cases but the
added complexity seems far outweigh the benefit.

All the above fall into the category of advanced features,
and their usage is completely optional. This way they should
not affect the basic IP over IB operation defined by the
existing IPoIB drafts.

<VK> OK. <VK>

Given the amount of concerns raised so far against 4), I'd like to
remove it from the list of consideration. If you have a problem with
that please bring it up to me and Bill. For the rest three I'll need
you to

1. show your interest and/or volunteer for the work
2. provide a concise description on what the item is, why it should
be considered (e.g. the benefit), and the deliverables

<VK> OK. I suppose this mail satisfies 1. above :-). Will do 2. <VK>

Jerry and Bill,
IPoIB co-chairs

_______________________________________________
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: Vivek Kashyap <[email-masked]>
Date: Fri, 6 Sep 2002 09:29:21 -0700 (PDT)

Bill, Jerry,

> routing/session establishment problems that have been brought forward?

Thanks
	Vivek

---

From: Thomas Narten <[email-masked]>
Date: Fri, 06 Sep 2002 14:31:22 -0400

> draft-kashyap-ipoib-advanced-capabilities-00.txt provide some of the

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)?

> routing/session establishment problems that have been brought forward?

Let me turn the question around and ask: what problem does 2) fix?
Would this be a mandatory-to-implement extension for all nodes?

Thomas

---

From: Caitlin Bestler <[email-masked]>
Date: Fri, 6 Sep 2002 13:51:22 -0500

On 9/6/02, Thomas Narten wrote:

>> 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/