Talk:Proposal:iNET-2008-ANTP

Background

Kewords from INET Documents

Telemetry Network System, Telemetry Network System Architecture, Integrated Network Enhanced Telemetry (iNET)

Limitations from INET Documents

1. It seems that there is an existing framework for the overall network from the functional point of view. What is unclear is how much of that is real architecture that must be used. For example, according to the TA architecture (pg 28) all the network and link layer protocols must be implemented in the "RF network element" that is connected to the peripherals and phy in a very specific way. Do we propose something that neatly fits in to this architecture? ANS: Partially yes; ask KIp how much they buy into this architecture.
2. The architecture also seems to be strongly dependent on IP. The reason for IP in the test network is that the peripherals (instrumentation) on the TA such as DAUs and video cameras are IP devices.
3. The motivation for the current architecture is earliest field deployment and not the best performance [A: TmNS ]

Key Concepts from INET Documents

Architecture

1. Even after implementing the networked links and multihop network, it is expected that some of the telemetry data will be streamed in real time. The proposed multihop network must support relaying of the SST signal. [A:TmNS TA, pp: 29]
2. The architecture also provides for a gateway at the GS for data transport between the RF network and the GNET (ground network). [A: TmNS GS GNET, pp 15]

Environmental Conditions and Challenges

Current

Spectrum: 1435-1525 MHz ; 1755-1850 MHz; 2200-2390 MHz;

Range Distance : 190 Nautical miles = 218.64 miles = 351.88 Km

Future

Spectrum: L, S, SHF and Non RF bands

Bandwidth : Tunable (what are the limits?)

Maximum Coverage : 5 to 500/5000 NM (~1000 KM/10,000Km) ; Long term : Global

Typical Coverage: 1 to 370 km

Maximum Throughput to and from a TA : 5 - 50 Mbps

Typical throughput to and from a TA: 1 or 2 Mbps in short term and upto 10 Mbps in long term

Most Stressing Latency : 100 msec with 100 msec variation

Speed : Max = [20mph Mach 2.5] ; typical = [4mph to Mach 2]

Altitude: Max = [65,000ft to 100,000ft] ; typical [12,000ft to 40,000ft]

Number of TAs in a test : Max = [2 to 2000] ; Typical [ 1 to 20 ]

Protocol Related Points

1. Network layer should be implemented as a part of the "RF Network Element" in the TA
2. Transport layer and any proxies should be implemented in the "vNET element" of the TA

Interaction with Existing Projects

1. Space time code project by BYU addresses signal masking caused by vehicle motion at the physical layer.
2. The current MAC algorithm project by JHU-APL, PI is considered a near term solution. What is the long term solution?

Points from INET Documents that bolster our case

1. The "Technology Shortfalls Appendix" specifically talks about the need to work on the transport and routing protocols for the iNET TmNS. Lines 28-66 and 116- 154.
2. The requirements for delay and reliability are given in the needs discernmenet document . pg 27-38

Main Ideas for the Proposal

1. Lets take and example and build on that. What do we need to do in this given scenario ..refer notes

1. Do we need to consider network issues beyond the ground stations?
2. Does the current TDMA MAC work address the issue of relaying the streaming data from TA to the GS?
3. BAA summary slide mentions: ."..... transition potential and technical feasibility high drivers during two-phased BAA review period.....". What does this mean to us?
4. Should SST be treated as an alternative transport protocol running over the new routing protocol.
5. Even though their current scheme limits at the speeds at 7 Mach; would they be interested in a solution that works at higher speeds ?
6. What is the connectivity pattern...do they expect to have continuous link connectivity to the test article?

Questions for Kip

1. What is the limit on the number of pages dedicated to figures ? ANS: You can trade text for figures
2. What is the data rate of the physical links? Docs say 5-50 Mbps; But is this overprovisoned for the known apps? ANS: Physical links are currently severely under provisioned
3. Should the proposed protocols strictly satisfy the system requirements as laid out in the TmNS requirements document? ANS: Yes, you should.
4. The documents refer to this is "proposed" architecture which is a little more cooked than "experimental architecture" and less cooked than "draft architecuture" . Are changes to the current architecture welcome? ANS: We did not ask this question
5. Is it a good idea to refer/cite iNET documents in our proposal. For example the "Technology Shortfalls Repor...page 14". ANS: Yes
6. How does SST fit into the new iNET architecture being proposed ? ANS: For now the idea is that SST forms a completely separate, non-interfering parallel path. Things could change in future; we could propose so
7. Can we assume access to the GPS coordinates, and trajectory informations (velocity, bearing)? ANS: Qualified Yes. GPS may be available at TA. However, state vector of velocity and bearing is available only after it is downloaded from the TA through secure channels at the GS.

Technical Questions

1. Why wasn't routing explicitly mentioned in the BAA as one of the topics?
2. Are we proposing anything under the "policy based management capability" section to manage QoS? Basically, this would mean that routing protocol should support the QoS schemes that are required by the management scheme (maybe?). Cross-layer implications?

1. What are (will be) the typical data rates of these channels? Do we care for the routing/transport overhead?
2. What level of data reliability is required?
3. What is the link level reliability in the proposed MAC?
4. Given the "best FEC codes" from Dr. Erik Perrins, how many retransmissions are required?

1. Where would we implement the proposed transport and routing protocols?
2. How is cross layering going to implemented give the already defined network and RF elements in both the TA and GS? The answers would significantly contribute towards the feasibility of the project.
3. What is SATCOM and how is that different from the standard RF links?

Technical Discussion

TCP Variants

Basic TCP

Mechanisms

• Three-way handshake for connection setup
• Slow Start
  • Congestion window starts at 2 MSS
  • Congestion window doubled every RTT (1 MSS added for each ACK)
  • Up to ssthresh, updated after each slow start
• Congestion Avoidance
  • Congestion window increased by 1 MSS each RTT
  • Duplicate ACKs sent when packet lost

Shortcomings

• Three-way handshake wastes 1 RTT
• Slow start wastes bandwidth
• Assumes congestion as cause of all packet losses

TCP Tahoe

Mechanisms

• Loss detected via ACK timer expiration
• Congestion window reduced to 1 MSS after packet loss & re-enter slow start

Shortcomings

• Slow start wastes bandwidth
• Slow start used after every packet loss (wrong for bit-errors)
• Resends all data sent after lost packet

TCP Reno

Mechanisms

• Loss detected via three duplicate ACKs
  • Halves congestion window
  • Fast retransmit lost packet
  • Wait for acknowledgement of entire congestion window
• Loss detected via timeout
  • Behaves as Tahoe

Shortcomings

• Same as TCP Tahoe
• Effect not as severe for bit-errors
• Fast recovery only works for single lost packet in transmit window

TCP New Reno

Mechanisms

• TCP Reno mechanisms
• Continues sending new data during fast recovery
• Can retransmit multiple lost packets or sets of lost packets
• SACK commonly implemented as an extension to New Reno

Shortcomings

• Substantial wasted bandwidth if packets reordered more than 3 sequence numbers.

TCP Westwood and Westwood+

Mechanisms

• Sender-side-only modification to New Reno
• Designed for high BWxDelay paths
• Estimates available based on ACK stream
  • Sets ssthreshold and congestion window based on bandwidth estimation at time of packet loss
• Probes for additional available bandwidth

Shortcomings

• Similar to New Reno
• Bandwidth estimation suffers when reverse traffic is present due to ACK compression (Improved in Westwood+)
• Can't use SACK

TCP Peach

Mechanisms

• Based on New Reno
• Probes for available bandwidth using low-priority dummy segments
• Sudden Start sends at close to available bandwidth estimate instead of slow-start
• Rapid Recovery retransmits lost data without backing off if transmission rate less than bandwidth estimation

Shortcomings

• Dummy packet transmission uses extra energy
• Can't adapt bandwidth estimation faster than RTT
• Can't use SACK

TCP Vegas

Mechanisms

• Timestamps every packet for RTT estimation
• Additive increases and decreases to congestion window
• Congestion inferred based on increase in RTT before packet loss occurs

Shortcomings

• Fairness not achieved when interoperating with other TCP versions (Vegas suffers)
• Must have accurate initial RTT estimate
• Can't use SACK

SCPS-TP

Mechanisms

• Session setup option negotiation
• Link BWxDelay estimate-based rate control
• Open-loop token bucket per link shared through routing
• TCP Vegas slow start and congestion avoidance
• ECN, EON
• Selectable loss-source assumption (congestion, corruption, link outage)
• Cross layer notification of link-layer corruption
• SNACK for reduced quantity of ACKs

Shortcomings

• Requires 3-way handshake session setup
• Requires ACK stream
• Requires all link BWxDelay product estimates set in advance

iNET Network Protocol

• Multiple packet types
• Multiple packet priorities
• Reliability requirement knob

Header Format

4b version
length
4b? precedence (knob from TP)
4b? type (knob from TP)
GPS coordinate at transmission time
16b? TA destination MAC address
16b? TA destination address
36b? HEC (header check)

IP packet tunneled?

iNET Transport Protocol

• Should not require handshake for session setup
• ACK stream should be optional
• Reliability
  • Multiple copies of packets
  • Erasure coding over single or multiple paths
  • ARQ (SNACK)
• Rate controlled sources
  • Use negotiated rate from MAC layer
• QOS support
  • High priority for command and control packets