Subject: [manet] DYMO WGLC and writeup

From: Joseph Macker <[email-masked]>
Date: Mon, 12 Jul 2010 11:02:20 -0400

I have received minimal concrete feedback on DYMO and am going to begin
doing a WG chair writeup please provide feedback if you have any ASAP.

-Joe

---

From: Henning Rogge <[email-masked]>
Date: Tue, 13 Jul 2010 19:40:03 +0200

> doing a WG chair writeup please provide feedback if you have any ASAP.
I just noticed two things while looking at the current DYMO draft.

First is that the examples are no valid packetbb encoding, the packet header 
seems to be missing.

Second I'm not sure what's the reason about the IP.ttl=255 for all DYMO 
packets. Is there a special reason for this ? If the DYMO packets are 
forwarded by the DYMO agents, a TTL of 1 would be better.

Henning Rogge

-- 
1) You can't win.
2) You can't break even.
3) You can't leave the game.
— The Laws of Thermodynamics, summarized

---

From: Ian Chakeres <[email-masked]>
Date: Tue, 13 Jul 2010 14:45:38 -0400

Good point about the packet header. I will add it.

"""
The IPv4 TTL (IPv6 Hop Limit) field for all packets containing DYMO
   messages is set to 255.  If a packet is received with a value other
   than 255, it is discarded.  This mechanism helps to ensures that
   packets have not passed through any intermediate routers, and it is
   known as GTSM [RFC5082].
"""

Please let me know if there is any other issue.

Thanks.
Ian

On Tue, Jul 13, 2010 at 1:40 PM, Henning Rogge <[email-masked]> wrote:
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>
>

---

From: Henning Rogge <[email-masked]>
Date: Tue, 13 Jul 2010 20:58:23 +0200

> Good point about the packet header. I will add it.
A single zero byte in front of the message will be enough.
 
> Please let me know if there is any other issue.
Maybe it might be a good idea to move this section into the "8.  Security 
Considerations" chapter, it's not really necessary for the DYMO itself, right?

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 14 Jul 2010 09:32:13 +0100

I've started reading through the latest draft, and will have
some comments (I have some so far, though in some cases they
may be answered later in the draft) but need to be able to find
the time to finish.

One obvious issue is that determining whether a protocol works
is not really very easy from just reading the specification.
(I'm certainly not going to be able to achieve that.) It really
needs (in the IETF phrase) running code, and at the latest
version. What's the state of play with that?

I don't actually completely agree with Henning's comment about packet
header. As described in RFC 5444, a protocol using it (e.g. DYMO) is
notresponsible for the packet header, although it may add to it. The
packet header is the responsibility of the MANET protocol multiplexing
process, not DYMO. So DYMO can just say "don't need to add to it". It
can say "here's an example suitable for DYMO", but it can't say "this
is what the packet header should look like".

-- 
Christopher Dearlove
Technology Leader, Communications Group
Networks, Security and Information Systems Department
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87,
Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ian Chakeres
Sent: 13 July 2010 19:46
To: Henning Rogge
Cc: Joseph Macker; [email-masked]
Subject: Re: [manet] DYMO WGLC and writeup

                    *** WARNING ***

  This message has originated outside your organisation,
  either from an external partner or the Global Internet. 
      Keep this in mind if you answer this message.

"""

Thanks.
Ian

On Tue, Jul 13, 2010 at 1:40 PM, Henning Rogge <[email-masked]>
wrote:
> - The Laws of Thermodynamics, summarized
>

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Henning Rogge <[email-masked]>
Date: Wed, 14 Jul 2010 10:45:08 +0200

> is what the packet header should look like".
The DYMO example includes IP-header, UDP-header and the DYMO data. If this 
means that there should be still some packetbb multiplexer, the example is 
misleading.

If it would only contain the DYMO message (without IP/UDP), the example is 
fine.

Henning Rogge
-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Neuenahrer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 15 Jul 2010 13:58:04 +0100

OK, some comments on DYMO-20. I'd just like to repeat the comment
below (that no one has responded to) on running code.

I have NOT followed the protocol in detail. This is largely down to
lack of time, but there is another reason that is in the following
point.

In many ways the biggest omission is what in NHDP/OLSRv2 we have
called an Overview and Functioning section, though that's only one
possible name. There is some of the material that would be in that
mixed in with the protocol description, but there are other parts of
the protocol that I for one could use some exposition on (for example
on the types of information as described in 5.2.1). I have a strong
suspicion that the IESG is going to want some such material. There's
a lot of things I'd like to see in such a section - some moved, some
new. That would also help that in the protocol specification I often
feel I'm wading through material and if implementing would be trying
to pick out what the actual specification is.

What I am sure (from experience) that the IESG will want (unless
the relevant ADs have changed) is not using notation like == without
explanation. Yes, we all have programmed in C and know what it means,
but that isn't sufficient.

Page 5 first complete paragraph "most other more" doesn't seem right.
I'd drop the "most other".

A question that would make me think in practice is running DYMO over
an 802.11 network (not of course the only case, but one of interest).
802.11 networks have the "grey zone" problem of differing unicast
and multicast ranges (typically the latter exceeding the former, but
less reliably). How that interacts with DYMO's unidirectional links
could be an issue. (In NHDP/OLSRv2 the link qualty mechanism is
typically used to ensure this.)

Terminology: Distance. 65,535 hops? I don't think so.

Bottom of page 6, what is a site-scoped address? (Not a site-local
address, which are deprecated.)

End of Section 4.1. I'd be worried that having said metrics are
optional, all nodes had better make the sae decision, as otherwise
looping can occur. That's a general issue with options, can they be
chosen independently, or not.

5.1.2 and other references to sequence numbers. The use of unsigned
and signed throughout isn't right. In particular when discussing
comparison of sequence numbers, simply saying subtract as signed
number is unclear. (Also getting it precisely correct with 0 excluded
is a little picky. That would make how we wrote this in OLSRv2 not
quite right.)

In section 5.3.1 you indicate to use expanding ring search by
reference to AODV. DYMO is intended to be Proposed Standard, AODV is
Experimental. There are definite downref issues here - maybe it being
an option might allow this, but I wouldn't bet on that. There's also
an ID referenced that might be an issue, I'm not sure.

Also in 5.3.1 the penultimate paragraph on page 19, I have no idea
how to make this unicast instead of multicast work. Where do the
IP addresses come from. Are we doing multiple transmissions?

Second and third paragraphs of 5.3.3. The second says SHOULD, then the
third explains why it needs this. That makes it a MUST rather than a
SHOULD. That's not the only SHOULD I think might have to be a MUST.

5.3.4 is a very very long uninterrupted section. Which I have not read
in any detail at all I'm afraid.

End of 5.4. First it says packets SHOULD be buffered, then it says
buffering can have problems (as it can - TCP can really be messed up,
though messing up TCP in MANETs is far too easy). Buffering in this
way isn't standard IP practice I believe, should a routing protocol be
modifying IP in this way? That's an area I'd be taking advice on.

It should probably be noted somewhere that if a message has a hop count
then that should be incremented when hop limit is decremented. I know
DYMO doesn't need hop count. It could specify hop count should not be
used, but maybe some extension - possibly related to expanding ring
search and variable timing information - might want it.

VALIDITY_TIME is not TBD, it is defined in RFC 5497, so shouldn't be in
the IANA section.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Dearlove, Christopher (UK)
Sent: 14 July 2010 09:32
To: Ian Chakeres; Henning Rogge
Cc: Joseph Macker; [email-masked]
Subject: Re: [manet] DYMO WGLC and writeup

                    *** WARNING ***

-----Original Message-----

                    *** WARNING ***

"""

Thanks.
Ian

---

From: Ian Chakeres <[email-masked]>
Date: Fri, 23 Jul 2010 17:52:42 -0400

Thanks a lot Chris for all the great feedback. I've handled all the
small nits in a new revision and will submit once submissions open.

If you have any other comments, concerns, or better yet suggested text
- please send them my way.

Thanks.
Ian Chakeres