EQUIP Connection JCP - PowerPoint PPT Presentation

1 / 18
About This Presentation
Title:

EQUIP Connection JCP

Description:

Implements the same connection-oriented equip.net abstraction API as TCP Connection ... Only data actually in the sending window is committed. Simple priority ... – PowerPoint PPT presentation

Number of Views:23
Avg rating:3.0/5.0
Slides: 19
Provided by: crgCsN
Category:

less

Transcript and Presenter's Notes

Title: EQUIP Connection JCP


1
EQUIP Connection JCP
  • Chris Greenhalgh (Jim Purbrick)
  • University of Nottingham

2
Contents
  • TCP
  • Qualities
  • Problems and issues
  • UDP characteristics
  • JCP
  • Design
  • Responses to problems and issues
  • Availability and experience
  • Plans

3
Qualities of TCP
  • Simple semantics
  • easy to use
  • Reliable
  • Totally ordered
  • Robust
  • Flow control
  • wont swamp the receiver
  • Congestion control
  • wont swamp the network
  • shares bandwidth reasonably fairly
  • Widely available

4
Problems with TCP 1 Delays from NAGLEs
algorithm
Can be Disabled
app
send
recv
app
But see also flow and congestion control
send-buf
1
2
5
Problems with TCP 2 Delays from packet loss
app
send-buf
send
recv
app
recv-buf
1
6
Problems with TCP 3 Limited buffer management
app
send-buf
send
recv
app
1
7
Other issues
  • Byte stream
  • No message boundaries
  • Packets do no correspond to application units
  • Large send buffer
  • Needed for performance on high RTT networks
  • But makes problem 3 worse
  • No priority system (since totally ordered)
  • No connection probing
  • Requires more ambiguous application-level
    keep-alives
  • Limited control over protocol timeouts (e.g.
    host)
  • No connection quality reporting

8
UDP
  • Message-based ?
  • Limited message size ?
  • No flow or congestion control ?
  • Unreliable ?
  • Different API and style of use ?

9
Jims Communication Protocol Design overview
  • Unicast, implemented over UDP
  • TCP-based flow and congestion control
  • Robust, fair
  • Message-oriented (rather than byte stream)
  • Per-message choice of (un)reliable delivery
  • Multiple priority levels
  • Totally ordered within each priority level
  • Implements the same connection-oriented equip.net
    abstraction API as TCP Connection
  • Easy to use runtime choice of protocol

10
JCP Delays due to NAGLEs algorithm
  • Resolution
  • No NAGLEs algorithm ?
  • Packet-based (rather than byte-based) flow and
    congestion control windows, so packet and byte
    count both bounded
  • C.f. TCP without NAGLE, (up to one packet per
    byte in the window)

11
TCP Recap Delays from packet loss
app
send-buf
send
recv
app
recv-buf
Lost!
1
1
1
1
2
2
1
2
2
RTT
2
2
ACK.1
2
1
1
1
1
2
1
1
2
1
2
ACK.3
2
12
JCP Delays from packet loss
  • Resolution
  • 1 unreliable
  • Sender discards 1 on sending
  • Receiver delivers 2 immediately and ACKs
  • 1 lower priority than 2
  • Receiver delivers 2 immediately
  • Resending and delivery of 1 as for TCP
  • Limitation
  • 1 reliable and same priority as 2
  • Same as TCP

13
TCP Recap 3 Limited buffer management
app
send-buf
send
recv
app
1
1
1
1
2
2
1
NAGLE, flow or congestion window
1
1
3
3
2
1
1 and 2superceded
ACK.2
3
2
1
2
3
2
3
2
3
2
3
1 and 2still delivered
2
3
3
ACK.4
2
3
14
JCP Limited buffer management
  • Resolution
  • Messages which are queued but not actually sent
    can be cancelled (e.g. 2 above)
  • Messages can be sent with higher priorities
    causing early-as-possible insertion into the
    sending window
  • Limitation
  • Messages which have actually been sent reliably
    must still be delivered reliably
  • Messages which have actually been send unreliably
    must still be ACKed for flow and congestion
    control

15
JCP Other issues
  • Message-based
  • Preserves message boundaries
  • Network packets correspond to application units
    (important for unreliability and priority)
  • Large send buffer
  • Still needed for performance on high RTT networks
    with reliable data
  • Only data actually in the sending window is
    committed
  • Simple priority system implemented
  • Includes connection probing (0.2 Hz default)
  • Per-connection control over protocol timeouts
  • Some connection quality reporting (limited?)

16
JCP Limitations
  • User-space implementation (less responsive)
  • TCP-like ACK-based flow and congestion control
  • Gives bursty behaviour in the face of losses
    (compare rate-based control)
  • Packet loss is assumed to signal congestion
  • Like TCP, and most IP work
  • Not always true with wireless networks
  • No forward error correction (FEC) capability
  • Priority scheme unvalidated
  • Very simple expression of (un)reliability
  • Future options max. retry time, max. resend
    count,

17
JCP Availability and Experience
  • Availability
  • EQUIP module/package equip.net
  • C and Java implementations
  • EQUIP dataspaces
  • equipu URL scheme
  • Experience
  • Bystander August2002
  • Successful partially connected tests
  • Ian anecdotal improvement

18
JCP Plans
  • Experimental comparison
  • EQUIP dataspace over TCP
  • EQUIP dataspace over JCP
  • IBM TSpaces
  • Local WaveLAN tests analysis
  • WaveLAN quality vs loss rates
  • JCP characteristics and responsiveness
  • Validation and analysis
Write a Comment
User Comments (0)
About PowerShow.com