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

From: Jari Arkko <[email-masked]>
Date: Fri, 07 Mar 2008 17:48:56 -0500

Stuart,

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

And sigh, I've been e-mail overload since then. Here's an answer:

>> >       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. 

That I do understand.

> Admittedly ROHC etc. may reduce it.

Right. This is why I'm saying this not the primary problem. There are
many things you could do with header overhead, and the case for
standardizing something based only on that would be weak.

>> >    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.

Ok. Please state so in the document.

>
>> > 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.

Ok. Is there an update to the document?

>> > 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.

Right. I think it would make sense to update the document to either
avoid talking about duplication, or being more explicit about the issues
you discuss above.

>> > 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.

Right. But keep separate the things you can keep separate.

Jari

_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 7 Mar 2008 19:31:58 +0100

Hi Stuart,

have you checked the new version of the documnt?

do you think your concerns have been addressed? Do you agree with the  
requirements expressed there?

Thanks, marcelo

El 13/02/2008, a las 7:03, Stuart W. Card escribió:

> At 04:31 AM 2/7/2008, Jari Arkko wrote:
>
>> I have reviewed this document. My detailed comments are further  
>> down...
>
> concerned with protocol overhead. Admittedly ROHC etc. may reduce it.
>
> 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 <[email-masked]> www.critical.com
>
> http://www.ietf.org/mailman/listinfo/mext