Download ACP-WGI08-IP04_AGW Presentation

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts
no text concepts found
Transcript
ATM Application Layer Gateway
An Application Layer Gateway for Air Traffic
Management Communication by Satellite
Erling Kristiansen
European Space Agency
Simone Patella, Massimo Mazzoccanti
Vitrociset
ICSSC 2008 San Diego
1
ATM Application Layer Gateway
ATM traffic profile
 Short messages
● The majority of messages are ~20 to a few hundred bytes
● Some longer messages (a few KB)
 Irregular, infrequent message interval
● Inter-message interval seconds to minutes, depending on flight phase
● Many different types of messages, each with its own pattern
ICSSC 2008 San Diego
2
ATM Application Layer Gateway
ATM transport layer issues
 ATM traffic is inelastic
● Traffic is generated by events
● (Time-triggered messages are also considered “events”)
 ATN TP4 reliable transport was designed for elastic traffic
(by the way, so was TCP)
● Speed of transmission is driven by the transport protocol
● Source is capable of slowing down if the transport tells it to
● Reliable transport insists on delivering all data, and delivering in
sequence.
ICSSC 2008 San Diego
3
ATM Application Layer Gateway
ATM transport layer issues
 There is a fundamental incompatibility between inelastic
sources and elastic transport
● As long as traffic volume is well below network capacity, and no
significant volume of retransmissions take place, all is well
● But if even mild congestion is encountered, all traffic is delayed.
● Significant congestion, even for a short time, may cause very large delays
to all traffic.
Timeouts may expire, causing unnecessary retransmissions, thus
increasing congestion further.
ICSSC 2008 San Diego
4
ATM Application Layer Gateway
ATM transport layer issues
 Congestion control
● ATM traffic to/from any given aircraft is very “thin”
○ Infrequent, mostly short messages
● TP4 and TCP congestion control was designed for large file transfers
○ Feed-back from receiver to sender via ACKs and ACK timing
● TP4/TCP congestion control does not work well with thin, intermittentt
raffic
○ Knowing that there was/wasn’t congestion one minute ago says
nothing about now.
ICSSC 2008 San Diego
5
ATM Application Layer Gateway
ATM transport layer issues
 In summary: 2 problems:
1. Congestion control is ineffective for the traffic pattern
2. Inelastic traffic over an elastic transport protocol
– Two approaches to mitigate this situation were investigated:
– Transport relay (“PEP”)
– Application layer gateway (“AGW”)
ICSSC 2008 San Diego
6
ATM Application Layer Gateway
Transport layer relay
More commonly known as
Performance Enhancing Proxy (“PEP”)
ICSSC 2008 San Diego
7
ATM Application Layer Gateway
Transport relay (PEP)
 The PEP is a transport layer proxy
● Breaks the e2e transport into 3 parts
○ Ingress network
○ Satellite link
○ Egress network
 Solves problem 1: the inadequacy of congestion control for
the traffic profile
 Does not solve problem 2: The incompatibility between
inelastic traffic and elastic transport.
ICSSC 2008 San Diego
8
ATM Application Layer Gateway
Transport relay (PEP)
ICSSC 2008 San Diego
9
ATM Application Layer Gateway
The Application Layer Gateway
(“AGW”)
ICSSC 2008 San Diego
10
ATM Application Layer Gateway
Congestion will happen
 Unless you have an extremely high over-provisioning of
bandwidth, you have to assume that
Congestion will happen
 And it will happen when you least want it: In an unusual
operational situation such as massive flight re-routing due to
bad weather or an incident
 You can reduce the incidence rate as much as you can afford
by providing more bandwidth, but you cannot reduce it to
zero.
 The only thing you can do when congestion happens is to
discard messages.
● Randomly or intelligently.
 With e2e reliable transport, there is no way the network can
discard traffic. Only the sending application can.
ICSSC 2008 San Diego
11
ATM Application Layer Gateway
Application gateway (AGW)
 The AGW is an application layer message proxy
● The AGW intercepts messages
● Transports the message to the peer AGW at the other end of the
satellite link
● The peer AGW delivers the message to the destination
 The AGW can re-order and discard traffic selectively
ICSSC 2008 San Diego
12
ATM Application Layer Gateway
Application gateway (AGW)
ICSSC 2008 San Diego
13
ATM Application Layer Gateway
Application gateway (AGW)
 AGW functionality
● The AGW builds a queue of messages to be sent over the satellite link
● The AGW attempts to build a schedule for transmission that meets the
CoS/QoS requirements for all messages
● If such a schedule cannot be built, congestion is present
● In case of congestion, the AGW will discard messages according to set
rules
ICSSC 2008 San Diego
14
ATM Application Layer Gateway
Application gateway (AGW)
 AGW rules may consider such elements as:
● Priority
● Time-to-live
● Context
 AGW rules might include such features as
● Try to deliver all within time-to-live (deadline scheduling), even if it
sometimes means low priority goes before high
● High priority before low if both meet deadline
● If a message supersedes another one (e.g. new position vs. old
position), new goes before old
ICSSC 2008 San Diego
15
ATM Application Layer Gateway
Application gateway (AGW)
 Solves both problem 1 and 2
 Drawbacks:
● AGW needs to know message formats
○ Must be updated if new messages are introduced or formats changed
● For some rules, AGW needs to know message context
● Incompatible with end-to-end encryption
 Extra benefits
● May serve as interface between heterogeneous technologies
○ E.g. ATN in the aircraft, TCP/IP on the ground
● “Future proof” for future network technologies
● Effectively decouples ground, satellite link, on-board network
ICSSC 2008 San Diego
16
ATM Application Layer Gateway
The AGW test bed
ICSSC 2008 San Diego
17
ATM Application Layer Gateway
Test cases
 4 types of test were carried out:
● Very light load.
○ The objective is to verify that the AGW interferes only minimally
with traffic when no congestion is present
● Very heavy load.
○ The objective is to verify that the AGW performs as designed under
heavy congestion. This test is not representative of any foreseen
operational situation
● Operational heavy load situation.
○ The traffic load in somewhat below congestion most of the time, with
short periods of congestion. The objective is to show that the AGW
can improve overall performance significantly under light congestion.
● Demonstration in a realistic ATC environment
ICSSC 2008 San Diego
18
ATM Application Layer Gateway
Test cases
 The tests were carried out with a mix of 3 types of messages.
● CPDLC (Controller-Pilot Data Link Communication). These are highpriority, urgent messages
● FLIPCY (Flight Plan Consistency). These were considered of medium
priority and urgency.
● ADS-C (Automatic Dependent Surveillance – Contract) reports. These
are regular position reports. Because the reports are repeated at rather
short, regular intervals, we considered these of low priority.
ICSSC 2008 San Diego
19
ATM Application Layer Gateway
Test bed results
HIGH PRIORITY MSGS
With AGW
Transmitted Messages
2500
2500
Messages delivered in Time
2500
1200
Average Delay
1369.45 ms
5441.99 ms
MEDIUM PRIORITY
MSGS
Transmitted Messages
With AGW
5000
5000
Messages delivered in Time
5000
5000
Average Delay
9879.62 ms
5465.45 ms
LOW PRIORITY
With AGW
Transmitted Messages
2500
2500
Messages delivered in Time
1657
2500
Average Delay
19863.17 ms
5480.58 ms
ICSSC 2008 San Diego
Without AGW
Without AGW
Without AGW
20
ATM Application Layer Gateway
Thank you for your attention
ICSSC 2008 San Diego
21