headers
Williams, Jim | 3 Mar 2003 20:40
Favicon

RE: SCTP mapping - Multiple Streams

> >I am guessing that most implementations will chose to
> >support one stream per association because it is simpler
> >and I don't see a performance down side.  However since
> >number of streams per association is negotiable, it is
> >fine to allow more.
> 
> On the contrary, there are major advantages to sharing
> the same association across multiple DDP streams
> consolidates acking, congestion control and setup.

The down side for the implementation is that two contexts
(stream and association) must be accessed for each
packet sent and received rather than one combined context.
This is a factor of two "cost" increase in one of the
more expensive aspects of protocol acceleration.  As
an implementer, I would not lightly incur this.
I don't see the advantages as particularly compelling.

> An integrated  RDDP/SCTP implementation SHOULD NOT presume
> there is only one stream per association unless it has
> very strong reasons to believe that there will only be a
> single stream between the two endpoints.

My understanding is that one end of an SCTP association
may specify one stream per association and the other
end has no choice but to comply as the number is negotiated
by the minimum of the two.  So there is no problem in
making such an presumption.  The implementation is 
simpler if separate associations are used for each
stream between endpoints.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Caitlin Bestler | 3 Mar 2003 21:24

RE: SCTP mapping - Multiple Streams

On 3/3/03, Williams, Jim wrote:

>> >I am guessing that most implementations will chose to
>> >support one stream per association because it is simpler
>> >and I don't see a performance down side.  However since
>> >number of streams per association is negotiable, it is
>> >fine to allow more.
>> 
>> On the contrary, there are major advantages to sharing
>> the same association across multiple DDP streams
>> consolidates acking, congestion control and setup.
>
>The down side for the implementation is that two contexts
>(stream and association) must be accessed for each
>packet sent and received rather than one combined context.
>This is a factor of two "cost" increase in one of the
>more expensive aspects of protocol acceleration.  As
>an implementer, I would not lightly incur this.
>I don't see the advantages as particularly compelling.
>
For an established association[1], the association is easily
found with the verification tag. From there the
source/destination addresses should be verified to
filter out spoofed packets.

That is true whether you have a "consolidated" context
or not.

>From there you need to perform per-stream processing.
This is a simple lookup within the context of the already
(Continue reading)

Permalink | Reply | 2 comments |
headers
Caitlin Bestler | 3 Mar 2003 22:13

RE: SCTP mapping - Multiple Streams (binding)

To be a bit more specific, the local interface that would
give control over SCTP Stream selection would be the
equivalent of a 'bind'.

If the ULP chooses to bind, the low 16-bits of the "port
number" would specific the SCTP or TCP port number. The
high (or next) 16-bits would specify the DDP Stream.
An application that was unaware of multiple streams would
bind Stream 0 by default, which even TCP supports.

If the application did not issue a bind, which is typical,
the DDP layer would choose the port and stream for it.

The adaptation protocol already includes a reset-notice
to inform the other side that a new DDP Stream has been
initialized.

This is one method. It would also be possible to use SLP
or some IB-CM equivalent to select streams. The benefits
of stream consolidation is not incompatible with maintaining
source level TCP compatability for the ULP.

Caitlin Bestler
http://asomi.com/CaitlinBestler/
Permalink | Reply | 0 comments |
headers
Jeffrey Mogul | 3 Mar 2003 22:32
Picon
Favicon

Reminder: NICELI Workshop on Network-I/O Convergence (deadline Mar 17)

[I'd like to remind people in the RDDP working group about this
workshop; the deadline (no extensions!) for submissions is
in two weeks.]

Inspired by the vigorous technical discussion on this mailing
list, and on other related lists, Allyn Romanow and I are
organizing a workshop directly concerned with RDDP, RDMA, and
related technologies.  We encourage anyone with something
interesting to consider submitting a paper or position
statement.

Here's a short blurb:

    Call For Papers: Workshop on Network-I/O Convergence:
    Experience, Lessons, Implications (NICELI)

    in conjunction with SIGCOMM 2003, Karlsruhe, Germany, August, 2003

    The performance and commodity price advantages of modern LANs have
    created a convergence of networks and I/O.  This convergence
    promises both price efficiencies and true interoperability, for
    storage and for cluster interconnect.  The NICELI workshop provides
    a forum for researchers and practitioners to discuss the merits,
    drawbacks, applications, and practical implications of protocol and
    implementation designs.  Approaches based on Internet protocols are
    of particular interest.  We invite submissions of research results,
    protocol design rationales, significant implementation experience,
    and architectural papers related to the convergence of networks and
    interconnect.  Both technical papers and position statements are
    welcome.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Randall Stewart | 4 Mar 2003 14:17
Picon
Picon

Re: SCTP mapping - Multiple Streams

Caitlin:

A minor point added to your excellent
comments...

Caitlin Bestler wrote:
> On 3/3/03, Williams, Jim wrote:
> 
> 
>>>>I am guessing that most implementations will chose to
>>>>support one stream per association because it is simpler
>>>>and I don't see a performance down side.  However since
>>>>number of streams per association is negotiable, it is
>>>>fine to allow more.
>>>
>>>On the contrary, there are major advantages to sharing
>>>the same association across multiple DDP streams
>>>consolidates acking, congestion control and setup.
>>
>>The down side for the implementation is that two contexts
>>(stream and association) must be accessed for each
>>packet sent and received rather than one combined context.
>>This is a factor of two "cost" increase in one of the
>>more expensive aspects of protocol acceleration.  As
>>an implementer, I would not lightly incur this.
>>I don't see the advantages as particularly compelling.
>>
> 
> For an established association[1], the association is easily
> found with the verification tag. From there the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Black_David | 5 Mar 2003 01:26

RDDP SF Agenda

The RDDP WG will meet twice in San Francisco,
1700 to 1800 on Tuesday, March 18, and
1530 to 1730 on Thursday, March 20.

The Problem Statement and Architecture drafts:
- draft-ietf-rddp-problem-statement-01.txt
- draft-ietf-rddp-arch-01.txt
will be WG Last Called on this list within the next few days
(WG Last Call will end after the SF meeting week) and will
not appear on the RDDP SF meeting agenda unless significant
technical issues arise on the mailing list in the interim.

The DDP and RDMAP drafts:
- draft-ietf-rddp-ddp-00.txt
- draft-ietf-rddp-rdmap-00.txt
will have brief time slots to describe what has
changed since Atlanta and deal with any open technical issues.

The SCTP mapping and generic applicability statement drafts:
- draft-stewart-rddp-sctp-02.txt
- draft-bestler-rddp-applicability-00.txt
are new since Atlanta, and will have meeting time on Tuesday
to discuss their contents, deal with any technical issues, and
determine next steps.  Requests will be made to accept these
as official RDDP WG drafts.

The bulk of the 2 hour meeting on Thursday will be spent on
TCP mapping issues, to which the following three drafts are
relevant:
- draft-culley-iwarp-mpa-02.txt
(Continue reading)

Permalink | Reply | 0 comments |
headers
Williams, Jim | 5 Mar 2003 16:00
Favicon

RE: SCTP mapping - Multiple Streams

Randall Stewart wrote:
> Caitlin Bestler wrote:
> > From there you need to perform per-stream processing.
> > This is a simple lookup within the context of the already
> > found association. This is the *only* step that having a
> > one-association / one-stream pairing would save.
> > 
> > Meanwhile it would avoid savings in association setup
> > (a four-way handshake), Acks (the overhead of which could
> > be shared with multiple  streams) and congestion control
> > (each stream would have to do its own slow start).
> > 
> > [1] An established association is where the performance
> > issues are most important. Matching an incoming SCTP packet
> > during association setup and teardown is more complex, as
> > is currently being discussed in the sctp-implementors list.
> >  
> 
> Another savings would be the amount of state.. A SCTP
> association (or TCP connection for that matter) is a
> fairly heavy weight thing.. it takes memory to hold
> all of that state blob that makes up the association/connection.
> On the other hand, each stream usually takes around 8 - 16
> bytes (depending on the implementation.. and I bet you
> could get it real low if you had the unordered optimization
> you mention previously)... As such this is much smaller
> than having N * sizeof(tcb) connections... Quite a
> signifigant savings...

I think you present some of the design tradeoffs and there's
(Continue reading)

Permalink | Reply | 501 comments |
headers
Black_David | 5 Mar 2003 16:24

WG Last Call: Problem Statement and Architecture

This message announces an informal Working Group
Last Call on the RDDP problem statement and architecture
drafts that are intended to become informational RFCs:

- RDMA over IP Problem Statement,
	draft-ietf-rddp-problem-statement-01.txt
- The Architecture of Direct Data Placement (DDP) And 
	Remote Direct Memory Access (RDMA) On Internet
	Protocols, draft-ietf-rddp-arch-01.txt

Due to the timing of the IETF meetings in San Francisco,
this WG Last Call will run slightly longer than typical -
it will end at 9am Eastern Time on Monday, March 31st,
giving everyone a full week after the IETF meetings
to review and comment on these drafts.

Editorial comments should be sent directly to the
draft editor: Thomas Talpey [Thomas.Talpey <at> netapp.com].
Technical comments and requests for changes must be
sent to the RDDP mailing list [rddp <at> ietf.org] for
discussion.

Thanks,
--David [RDDP WG chair]

----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david <at> emc.com        Mobile: +1 (978) 394-7754
(Continue reading)

Permalink | Reply | 0 comments |
headers
Caitlin Bestler | 5 Mar 2003 17:52

RE: SCTP mapping - Multiple Streams

On 3/5/03, Williams, Jim wrote:

>Randall Stewart wrote:
>> Caitlin Bestler wrote:
>> > From there you need to perform per-stream processing.
>> > This is a simple lookup within the context of the
>> > already found association. This is the *only* step
>> > that having a one-association / one-stream pairing
>> > would save.
>> > 
>> > Meanwhile it would avoid savings in association setup
>> > (a four-way handshake), Acks (the overhead of which
>> > could be shared with multiple  streams) and congestion
>> > control (each stream would have to do its own slow
>> > start).
>> > 
>> > [1] An established association is where the
>> > performance issues are most important. Matching an
>> > incoming SCTP packet during association setup and
>> > teardown is more complex, as is currently being
>> > discussed in the sctp-implementors list.
>> >  
>> 
>> Another savings would be the amount of state.. A SCTP
>> association (or TCP connection for that matter) is a
>> fairly heavy weight thing.. it takes memory to hold all
>> of that state blob that makes up the
>> association/connection.
>> On the other hand, each stream usually takes around 8 -
>> 16 bytes (depending on the implementation.. and I bet
(Continue reading)

Permalink | Reply | 501 comments |
headers
Michael Krause | 6 Mar 2003 00:32
Picon

RE: Marker Interval

At 11:37 AM 2/24/2003 -0800, Larsen, Roy K wrote:
> > -----Original Message-----
> > From: Michael Krause [mailto:krause <at> cup.hp.com]
> >
> > At 09:42 AM 2/24/2003 -0800, Somesh Gupta wrote:
> > >The discussion is related to existing software stacks and
> > >interfaces. For storage protocols (as is for iSCSI), this
> > >forms the first wave of client side implementations.
> >
> > Again this is a function of implementation and a well-layered
> > implementation can be delivered without requiring any network stack
> > modifications if desired.  Same applies to software based
> > iSCSI which has
> > been demonstrated by multiple vendors without network stack
> > modifications.  Some of these implementations now deliver sufficient
> > performance that current customers using them are not raising
> > any major
> > objections.  Given this can be done with iSCSI and markers
> > are clearly less
> > complex to implement / support in software than iSCSI, one
> > might argue that
> > the complexity / cost issues are not as high as some assert.
>
>Mike,
>
>Marker use in iSCSI is a negotiated option.  Do you know if these successful
>software iSCSI implementations are running with markers enabled?

We have implemented it (was not that complex for our initiator) but have 
not tested it with a target as yet.
(Continue reading)

Permalink | Reply | 6 comments |

Gmane