Re: [MEXT] review of draft-ietf-mext-aero-reqs

["Stuart W. Card" <stu.card at critical.com>]

At 04:31 AM 2/7/2008, Jari Arkko wrote:

>I have reviewed this document. My detailed comments are further down...

Thanks for the comments. I have interspersed my own. Sorry it took me
so long to send them.

> >       Increased packet overhead - Given the constrained link bandwidths
> >       available in even future communications systems for aeronautics
> >       and space exploration, planners are extremely adverse to header
> >       overhead.  Since any amount of available link capacity can be
> >       utilized for extra situational awareness, science data, etc.,
> >       every byte of header/tunnel overhead displaces a byte of useful
> >       data.
>Secondary issues like this are not very convincing (what about header
>compression, for instance?) and confuse the key problem.

This is not a "secondary issue" in my world: link speeds of 128 kbps down
all the way to 2400 bps half-duplex with long turn-around times; we are very
concerned with protocol overhead. Admittedly ROHC etc. may reduce it.

> >    Since for ATS, the MRs and MNNs are under regulatory control and are
> >    actively tested and maintained, it is not unreasonable to assume that
> >    special patches or software be running on these devices to enable
> >    NEMO RO.  In fact, since these devices are accessed by skilled
> >    technicians and professionals, it may be acceptable even if complex
> >    configuration is required for NEMO RO.  Of course simplicity in setup
> >    and configuration is desirable, however.
>What about CNs, is it reasonable to expect changes to them?

No: in many cases, they may not even know that they are communicating
with an aeronautical mobile.

> > The set of CNs may be assumed to
> >    all share the same network prefix.
>This seems unexpected. Why would we assume this?

I agree with your comment.

> > If duplicating a small number of packets sent over
> > both the MRHA tunnel and the optimized path is possible until the
> > optimized path can be verified to function for a particular data
> > flow, then this could be sufficient to meet this requirement (it is
> > safe to assume that the applications are robust to this duplication).
>
>I am not sure I understand the transport implications of such
>duplication. I could imagine under some conditions it could introduce
>reordering or something that causes harm for TCP.

It is not the duplication that troubles TCP, but the possibility
of sending _different_ packets over different paths: if packets
N and N+2 both go over a fast path, and packet N+1 over a
slow path, then the receiver is likely to erroneously declare
that packet N+1 has been lost, and issue a DUP ACK of N.
If this happens too often, TCP based applications will fail,
due to exponential backoff, while the wireless links are filled
with needless retransmissions. Fortunately there are TCP
dialects that are immune to this, such as SCPS-TP, but
they are far from universally used.

> > For oceanic flight, ATS and AOS may
> >  also benefit from the capability of nesting MRs between multiple
> >  planes to provide a "reachback" to terrestrial groundstations rather
> >  than relying solely on lower rate HF or satellite systems.  In either
> >  case, this mode of operation is beyond current strict requirements
> >  and is merely desirable.
>
>This requirement makes sense to me, but it is also something that
>focuses on building ad hoc routing style networks. I would suggest that
>we have to keep this part of the problem space out of our effort if we
>are going to complete something. Lets look at the ad hoc routing aspect
>separately.
>
>I also do not necessarily believe that nested NEMOs are the right
>approach to doin such multi-hop manet routing. It seems preferrable that
>the MR deals with this by also acting as a, say, MANET router.

Whether this is handled as nested NEMO, MANET or MANEMO,
for U.S. DoD airborne networks, the capability for one aircraft to relay
on behalf of another is a hard requirement, not just a desirable feature.

This is my most urgent comment. I have cc'ed a couple of members
of our team who are not regular participants in MEXT, as they may be
interested in this discussion in general, and that point in particular.

Thanks to the authors for this fairly comprehensive draft!

Stuart W. Card, Chief Scientist & VP, Critical Technologies Inc.
* Creativity * Diversity * Expertise * Flexibility * Integrity *
Suite 400 Technology Center, 4th Floor 1001 Broad St, Utica NY 13501
315-793-0248 x141 FAX -9710 <Stu.Card at critical.com> www.critical.com

_______________________________________________
MEXT mailing list
MEXT at ietf.org
http://www.ietf.org/mailman/listinfo/mext