1 / 7

SCTP Draft

SCTP Draft. DDP Stream establishment issue identified Dynamic Protection Domain selection assumes local interface supports deferred Protection Domain assignment. Should be documented at the minimum. Not compatible with traditional local interfaces.

nicholashutchinson
Download Presentation

SCTP Draft

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SCTP Draft • DDP Stream establishment issue identified • Dynamic Protection Domain selection assumes local interface supports deferred Protection Domain assignment. • Should be documented at the minimum. • Not compatible with traditional local interfaces. • Draft under author-review to support single-message exchange before stream is associated with an endpoint. • Compatible with private data exchange described in current MPA draft. • No other issues identified.

  2. Shared Receive Queues vs. Shared Buffer Pool • Shared Receive Queues proposed in draft-hilland-verbs-00. • Not yet reviewed by the WG, a requirements round may be needed first. • But presence/absence has impact on other drafts. • Architecture: definition/existence of “post receive” operation. • Security: certain vunerabilities may be specific to Shared Receive Queues as opposed to RDMA in general.

  3. The problem: the need to under-provision receive buffers for servers • 100,000 DDP Streams allowed 6 in-flight untagged messages each requires 600,000 committed buffers. • But network topology might make it impossible for more than 50,000 to show up in the time it takes to process and release a buffer. • Proposal: allow ULP servers an option to pool buffers within an application when ULP is confident that lower number of buffers is adequate. • Two mechanisms proposed: • Shared Receive Queue - as in draft-hilland. • Shared Buffer Pool - as in emails from Caitlin Bestler

  4. Non-shared Model • ULP enables one untagged receive by pre-posting a receive buffer to the DDP Stream’s “Receive Queue”. • If N have been posted, then a range of N Message Sequence Numbers (MSNs) can be accepted. • Peer sending “too much” will have out-of-range MSN, resulting in stream teardown.

  5. Shared Receive Queue Model • DDP Stream optionally associated with a Shared Receive Queue, rather than its own. • ULP enables reads by pre-posting to a shared receive queue. • Invalid message detection by buffer exhaustion (adjusting for implied buffers). • Asynchronous notice configurable for a stream if it exceeds its limits, but no DDP layer action is taken against the stream.

  6. Shared Buffer Pool Model • DDP Stream optionally configured to obtain buffers from Shared Buffer Pool, but untagged message credits still tracked for each DDP Stream’s “Receive Queue”. • DDP Stream exceeding MSN window will be terminated, just as for non-sharing streams. • No chance of abusive stream draining available buffers. • No chance of available buffers being “leant” to recover a stream that had slipped into temporary non-compliance.

More Related