RSVP Transport Issues

1
RSVP Transport Issues

• Ping Pan
• Henning Schulzrinne

2
Issues

• Reliable Messaging
• Reliable delivery soft-state.
• Solution Staged refresh timers (RFC2961).
• very TCP-like, at per-session level.
• Message Packing
• One session per RSVP message.
• The size does not matter. It is the message
  count that kills the CPU.
• Solution Message Bundling (RFC2961)

3
Issues (cont.)

• RSVP MTU
• Cannot handle fragments.
• Not an issue in RSVP-TE.
• In e2e, message size may increase due to security
  overhead.
• RSVP-TE vs. real-time applications
• RSVP-TE does not have scaling problems.
• Always enable RFC2961
• Controlled triggered messages
• Real-time applications may have a problem.

4
Where do we go?

• RSVP-TE no thanks.
• Already deployed RFC2961.
• 50,000 sessions per router.
• Other applications
• Transport layer may be a concern.
• Recommendation on transport layer
• Make it flexible.
• Make it TCP-like,
• and make it simple.

5
Only if we could have done it again

• Learn from RSVP
• Application-neutral.
• Change 1 hop-by-hop messaging
• No need of using IP Router Alert for PATH
• Change 2 flexible message transport
• Support multiple transport protocols raw mode,
  TCP, or UDP.
• Swap transport-layer protocol per-hop

6
How does it work
Hello, negotiation
Step 1
A
B
D
C
TCP
Raw mode
TCP
Step 2
A
B
D
C
Bundling
User Requests
Step 3
A
B
D
C