Status of MII Project SLP Work

1
Status of MII Project SLP Work
2
What is SLP?

• Service Location Protocol is a new IETF standards
  track protocol for discovering services on IP
  intranets.
• A service is any network accessible hardware
  device or software server.
• Examples Printers, file servers, video cameras,
  HTTP servers, etc.
• Discovery is the process by which potential
  clients of the service obtain enough information
  to access the service.
• Replaces or supplements proprietary service
  discovery protocols such as
• Appletalk NDS
• NetWare SAP
• Microsoft CIFS Browsing Protocol

3
SLP Architecture
4
Current Status

• Solaris SLP transferred to Solaris Products group
  4/99.
• Portable small profile Java SLP transferred to
  Consumer and Embedded division 3/99.
• Portable small profile Java SLP also available on
  Linux.
• Portable small profile C SLP released 11/98.
• Runs on Win32, Linux and Solaris.
• Ongoing work to bring API up to RFC2614.
• Third and final release expected shortly.
• Ongoing work to remove licensing restrictions so
  commercial use is possible (I.e., a reference
  port).

5
Disconnectable File Systems
6
File Systems on the Move

• Local storage as a cache
• during periods of faulty or varying network
  conditions
• Local storage as a disconnected cache
• during periods of no network connectivity
• Populating the cache
• user initiated (filesync, PFS)
• user transparent
• Synchronizing the cache
• user initiated (filesync)
• user transparent (PFS)
• may involve the user to resolve inconsistencies
  or conflicts

7
Filesync

• User initiated
• populating the cache
• synchronization
• very deterministic
• Port of Solaris 2.6 source to Linux
• Some new routines
• nftw - new file tree walk
• Added a graphical user interface (GUI) based on
  Tcl/Tk
• In regular use for nearly a year
• Status not released

8
PFS

• User transparent synchronization
• not entirely deterministic
• T.Tateoka student intern from University of
  Electro Communications (Tokyo)
• Dynamic adaptation to network conditions
• Supports disconnection
• Implemented entirely in user space
• Status released under GPL!
• http//www.spa.is.uec.ac.jp/tate/pfs/

9
Conclusion

• Environment on the go is very useful
• Development possible in any environment
• home
• cafeteria
• hotel
• Debugging of network software
• software under development sometimes (gasp!) does
  not work
• leads to lack of connectivity
• cannot depend on the network to access debugging
  environment and source tree
• Filesync has helped our MII development

10
Optimizing Internet Protocols for Wireless
11
Network Characteristics

• Corruption and Errors caused by the wireless
  medium
• TCP assumes that packet loss equals congestion
• TCP then backs off
• correct and desirable behavior in wired internet
• contrary to what corruption/error losses need
• Wireless has higher latency
• bandwidth can be improved
• latency is more difficult
• avoid round trip times like the plague!
• Proxies are common, but
• introduce dependencies
• may break end-to-end semantics
• should be viewed as optional

12
Constraints and Assumptions

• Small footprint
• Modify only devices and perhaps intermediate
  systems
• Readily deployable

13
No Need for a Smaller Spec

• TCP/IP is small enough
• KA9Q (Phil Karn) 12KB
• TCP 10KB
• IP 1.8KB
• PPP 14KB (is HDLC-like framing enough?)
• Smartcode Embedded NetCore IP 14KB
• http//www.smartcodesoft.com/service/service.html
• STN 30KBwith PPP
• http//www.stnc.com
• Conclusion TCP/IP takes less than 15KB

14
Optimizing Long Thin Networks

• From http//search.ietf.org/internet-drafts/draft-
  montenegro-pilc-ltn-02.txt
• Fix the link with FEC and (limited)
  retransmissions
• Implement error-resilient header compression
  (RFC2507,RFC2509)
• Path MTU discovery (RFC1191)
• TCP congestion control (RFC2581)

15
Optimizing LTNs (cont)

• TCPs initial window to 2 segments (RFC2414)
• ACK without delay the first segment in a new
  connection
• HTTP1.1
• persistent connections (vs T/TCP)
• Content-Encoding deflate and "Accept-Encoding
  deflate
• http//www.w3.org/Protocols/HTTP/Performance/Pipel
  ine.html
• SACK (RFC2018)
• ECN (RFC2481) and RED (RFC 2309)
• TCP control block interdependence (RFC 2140)
• althoughHTTP1.1 persistent connections already
  helps

16
IETF PILC WG Status

• Long Thin Networks rev 03 to informational
• Others slated for best current practices
• advice for IP subnetwork designers
• slow networks
• error prone networks
• performance-enhancing proxies (PEPs)
• asymmetric networks

17
Conclusion

• TCP/IP protocols
• Are small enough
• Are adaptable and most definitely NOT broken
• Benefit from open review by world experts (PILC,
  W3C)
• Are public and openly implementable
• Allow optional proxy services, but do not require
  them
• Do not break the end-to-end principle (so IP
  security could work, for example)
• Are scalable much beyond current wireless
  bandwidths