Subject: RE: [Ipoverib] Yokohama IETF

From: "Jerry Chu [expiry 14 July 02]" <[email-masked]>
Date: Wed, 3 Jul 2002 13:12:13 +0800 (CST)

Do we believe this is architecturally feasible at all, given the
end2end nature of TCP/UDP checksum, and the presence of middlebox
or tunneling that makes the determination of where TCP/UDP pkts
actually terminate tricky? (One must ensure the complete path lies
within a single IB RC.)

Jerry

> Vivek,
> 
> Maybe we can add to the IPoIB RC a feature we once discussed
> For TCP/UDP checksum offloading no need to specify the exact method now
> Just mention it is a possible future goal
> 
> Yaron
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Vivek Kashyap
> Sent: Friday, June 28, 2002 1:45 AM
> To: [email-masked]
> Cc: 'Jerry Chu'; 'ipoverib'
> Subject: Re: [Ipoverib] Yokohama IETF
> 
> Jerry, Yaron,
> 
>         As you know these ideas have been proposed by me in the draft:
> 
>         draft-kashyap-ipoib-advanced-capabilities-00.txt.
> 
>         I had presented a set of slides at IETF-53. See slides 16 to 24 at:
> 
>         http://www.ietf.org/proceedings/02mar/slides/ipoib-1/index.html
> 
> Vivek
> 
> PS. I won't be attending IETF-54.
> 
> >
> > Jerry,
> >
> > Regarding the extra topics:
> > I think the IPoIB over RC is important to improve both performance and
> > robustness
> >
> > The demuxing to few QP's might be useful too for some applications
> >
> > Another thing that IB ARP can help in is detecting SDP (Socket Direct)
> > clients e.g. through a capability bit
> > I'm not sure if it requires changes in the WG charter
> >
> > Yaron
> >
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On Behalf Of
> > Jerry Chu
> > Sent: Friday, June 28, 2002 12:57 AM
> > To: ipoverib
> > Subject: [Ipoverib] Yokohama IETF
> >
> > With the Yokohama meeting fast approaching, it is
> > time to prepare for the agenda. We need to first
> > decide if there are enough topics to discuss. What I
> > need from you are -
> >
> > 1. how many of you are planning to attend the meeting
> > 2. how many have slides to present (including the topic)
> >
> > Please let me know asap. Even if you can't make it to
> > Yokohama in person, you can still make slides and give
> > them to me. I will present the slides on your behalf.
> >
> > On a separate topic, the three basic drafts for IPoIB communication
> > listed below
> >
> > draft-ietf-ipoib-link-multicast-02.txt
> > draft-ietf-ipoib-ip-over-infiniband-01.txt
> > draft-ietf-ipoib-dhcp-over-infiniband-01.txt
> >
> > have gone through several rounds of review and seem
> > to be in pretty good shape for a WG last call, pending
> > the resolution of the promisucous multicast mode
> > support. Bill and I would like to see if there is
> > enough interest to extend the current WG chart to
> > cover a number of more advanced features such as
> >
> > 1. running IP over non-UD IB transports
> > 2. demultiplexing IP packets into multiple QPs based
> > on, e.g. layer 4 fields
> >
> > This is the time to bring up any remaining topics
> > you may have for the WG to cover. Note that in order
> > to get the permission from the ADs to add any work
> > group item to the current charter, the item must be well-defined and
> > scoped, with enough interest from the WG to support the work.
> >
> > Your friendly co-chairs
> > Jerry and Bill
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > 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
> 

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

---

From: Michael Krause <[email-masked]>
Date: Tue, 02 Jul 2002 22:25:54 -0700

>actually terminate tricky? (One must ensure the complete path lies

Been tried many times and no one has come up with a good solution.  I don't 
think this is a worthwhile effort to pursue.  Put a checksum off-load 
engine within the CA and do some fix-up if need be just like what is done 
for Ethernet and we don't need to specify anything here to solve this problem.

Mike