Subject: [Mip6] MONAMI Draft - Aviation Input

From: "Davis, Terry L" <[email-masked]>
Date: Wed, 25 Jul 2007 11:51:30 -0700

Aviation Community

Please consider inputs or comments to this IETF draft as they are adding
some aviation requirements to it.

http://www.ietf.org/internet-drafts/draft-ietf-monami6-multihoming-motiv
ation-scenario-02.txt 

This document will go to "last call" in August after which time it will
be too late for us to input.

Take care
Terry

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: "Davis, Terry L" <[email-masked]>
Date: Fri, 27 Jul 2007 09:17:41 -0700

Tony

Thanks!  We will re-drafting at least our inputs via the current
aviation requirements draft which will go out next month.  Wes Eddy is
the current author and is an FAA contractor so I cc'd him.

Take care
Terry

> -----Original Message-----
> From: Tony Whyman [mailto:[email-masked]]
> Sent: Friday, July 27, 2007 8:14 AM
> To: (Mobile Platform Internet Mailing List); Davis, Terry L
> Cc: [email-masked]; [email-masked]
> Subject: Re: [MPI]MONAMI Draft - Aviation Input
> 
> Terry,
> 
> I am writing this response to your call for comments whilst on
vacation
> and sipping a cold beer on a Greek Island. I say this not so much as
to
> make readers envious (of course) but as a disclaimer for what goes
below
> as I may not have read the draft in the detail I should have, and to
> point out how useful a mobile technology is GPRS as otherwise how
could
> I read my EMail on an island in the middle of the Aegean.
> 
> 1. The draft seems not to mention one of the problems that has plagued
> the ATN - which for want of a better name I will call the need for
> symmetry. That is to ensure that the path from mobile to fixed is the
> largely the same as the reverse. This is needed partly to avoid
problems
> with measuring the loop delay time, but more importantly to ensure
that
> the fixed to mobile packets follow the intended path. It's no good the
> aircraft always carefully selecting VDL over SATCOM for downlink
> messages if the ground then uploads a mega message via SATCOM.
> 
> This is not a randomly chosen example. It was the one given by the
> airlines as an example of cost based route control. It was based on
the
> assumption that SATCOM was more expensive than VHF and that airlines
> wanted cost control over both directions of transfer.
> 
> Essentially, the requirement is that the mobile must be able to direct
> the remote system to use a given interface for data transfers even
when
> other interfaces are available.
> 
> 2. Returning to that same example, while AOC data may have 'cost' as
its
> basic selection metric, ATC data has reliability as its selection
metric
> and this may result in a different choice of preferred interface.
> 
> The requirement over interface choice is not system based, it is
> application based and, again I don't feel this comesout of the draft
as
> the examples there seemed to assume that only a single application was
> active at any one time.
> 
> 3. Under the heading  "lessons learnt from the past", it's worth
> recalling that one of the goals of the OSI Network Layer was to hide
> routing from the user and as interfaces were also hidden, this made
for
> a complex problem whereby an application had to clearly indicate its
QoS
> requirements for each packet and the routing process in every
> intermediate system had then to interpret them (symmetrically). Hence
> the complex IDRP based solution in the SARPs.
> 
> On the other hand, if interfaces and route choice are not hidden from
> the application, it is possible for applications to keep each other
> up-to-date on available interfaces or more specifically, the mobile
> network(s) that are available. The routing process is then simplified
at
> the expense of demanding a sub-protocol that allows the applications
to
> keep their peers up-to-date on route choice, which can then be
expressed
> in terms of the destination IP Address and perhaps some additional QOS
> metrics, rather than having to express everything in terms of QOS.
> 
> The issue here is what is the correct trade-off between information
> hiding in the network and application participation in route
selection.
> Alternatively this may be expressed as the trade off between router
> complexity and end system complexity. This issue does not seem to come
> clearly out of the draft.
> 
> Anyway, that's all - the sea beckons and I can't think of anything
more
> for now.
> Regards
> Tony Whyman
> Davis, Terry L wrote:
> > #############################################################
> > This message is sent to you because you are subscribed to
> >   the mailing list <[email-masked]>.
> > To unsubscribe, E-mail to: <[email-masked]>
> > To switch to the DIGEST mode, E-mail to
<[email-masked]>
> > To switch to the INDEX mode, E-mail to <[email-masked]>
> > Send administrative queries to  <[email-masked]>
> >
> >
> >