Subject: Re: [dtn-interest] Fwd: New version of PRoPHET draft published

From: 오승훈 <[email-masked]>
Date: Thu, 7 Jul 2011 17:34:35 +0900

Hi.

In the version -09,  in order to reduce distortion of the delivery
predictability (DP) it makes P_encounter a function of the interval since
the last encounter resulted in an update of the DPs. 
It seems that it will works well in the case where the closely spaced
communication opportunities take place. 
However, if the intervals between encounters are relatively long (larger
than I_typ) but the duration of each encounter is too small to be a good
forwarder for each other, it will not work properly. In this case
P_encouter will be P_encouter_max, every encounter will increase the DP by
the same amount as the normal mobility pattern case. I do not think it is
appropriate.  
It is intuitively reasonable that the longer, and the relatively more
stable the encounter which nodes have with their neighbors is, the higher
their DP values should be. 
In that sense, it would be appropriate to make P_encounter a function of
the contact duration rather than the interval since the last encounter. 

Any comment would be welcomed. 
Thanks
Seung-Hun Oh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Joerg Ott
Sent: Tuesday, June 28, 2011 8:31 PM
To: [email-masked]
Subject: [dtn-interest] Fwd: New version of PRoPHET draft published

All,

the authors have submitted a revised version of the PROPHET I-D, now
version -09: http://tools.ietf.org/html/draft-irtf-dtnrg-prophet-09

Since there were quite a few changes and additions, we would like to re-
issue a research group last call on this.  Please comment within two weeks
(i.e., by 11 July).  Ideally, please comment a few days earlier so that the
authors can roll updates into the document before the I-D deadline.

Please direct your comments to the mailing list and/or the authors.

Thanks,
Joerg

-------- Original Message --------
Subject: [dtn-interest] New version of PRoPHET draft published
Date: Mon, 04 Apr 2011 19:54:41 +0100
From: Elwyn Davies <[email-masked]>
To: DTN-interest <[email-masked]>

Hi.

We published a new version of the PRoPHET draft on 3 April that contains a
number of improvements and clarifications that have come out of further
theoretical study and practical work in reimplementing the protocol.

The new draft can be found at
http://tools.ietf.org/html/draft-irtf-dtnrg-prophet-09

Readers will find that there is quite a lot of extra text providing
additional guidance for implementing the protocol state machine and
explaining the operation of the protocol.  However, both the theoretical
basis and the operation of the state machine are fundamentally unchanged.

The new version of the protocol will not be compatible with the existing
implementations because we identified that the existing protocol had got
out of step with the main bundle protocol in two ways:
- it was unable to offer or accept bundle fragments, and
- the bundle identifiers used were missing the source EID.
Regrettably none of us had noticed these issues until relatively recently.
Updating existing implementations to match the new specification is not
expected to be too onerous but the updates have necessitated new versions
of the Bundle Offer/Response TLVs.

Apart from this practical matter, we have identified solutions to two
issues that have been seen in deployments of the protocol.  the solution to
the first of these was in the previous (-08) version of the protocol.  The
second replaces a proposal for suppressing updates in certain cases that
was criticised in the previous draft. We believe the new solution is more
effective and improves behaviour in several situations.

The first solution was the modification of the 'transitive' update equation
(number 3) in Section 2.1.2.  The new function improves the behaviour of
the protocol in situations where nodes repeatedly exchange information
about nodes which they have not directly encountered.

The second, and new, solution involves adding some limited time dependence
to the P_encounter parameter used in the direct encounter equation
(Equation 1).  This time dependence reduces the exaggeration of the
delivery predictability for direct encounters caused when the communication
link is intermittent and results in multiple closely spaced (in time)
communication opportunities that are, from the overall schedule point view,
a single logical encounter.  This change combined with the change to the
transitive equation also results in more stable behaviour when a number of
nodes come to a common location and each node has simultaneous or closely
spaced communication sessions with several other nodes.
The draft also includes some additional description of the various
parameters used, together with discussion of how to relate these parameters
to more usual descriptions of mobiloty patterns.  Appendix C has been added
which explains one method of calcuilating values for the parameters
(especially gamma and P_encounter_max) from the expected values of various
time distributions realted to the mobility pattern.

In addition to these improvements to the methods used to evolve the
delivery predictabilities, the description of the state machine has been
improved and expanded, both by the addition of high level description and
the clarification of the detailed functionality.  A minor change to the
state machines has been made to clarify the behaviour of the system when
two nodes remain in communication for a longer period when there may be
multiple information exchanges. Apart from the additions to the Bundle
Offer/Response TLVs mentioned above, the changes to the methods and the
state machine should not significantly impact the packets on the wire - the
hello process and basic information exchange are unchanged.

Detailed changes to the state machine include:
- Ensuring that the machine will operate correctly in both concurrent and
serial modes,
- Ensuring that when using a reliable in order delivery transport all of
the types of information exchanged can be carried in multiple messages if
appropriate,
- Clarifying the error behaviour - basically ensuring that the transport
link is aborted in most cases if errors indicate that there is a problem,
and
- Improving the explanation of what happens after an initial information
exchange.  In practice, many communication opportunities barely last long
enough to carry out a single information exchange, and the protocol had not
been much exercised for subsequent exchanges.  The intended operations
proved to be better described by using an additional state in the Initiator
role rather than having the Initiator and Listener roles perform a 'join
transition' as was previously expected.
We believe that this new version addresses a number of comments that we
received when the protocol was last presented to the DTNRG at the
Maastricht IETF meeting, and we have done considerable theoreticaland
practical work to improve the protocol.

We think that this version is now in a good state to go forward for
publication as an RFC. We expect that we need to repeat the RG last call on
the document and look forward to any comments that we receive.

Regards,
Elwyn Davies (ed),
Avri Doria,
Samo Grasic, and Anders Lindgren
_______________________________________________
dtn-interest mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/dtn-interest

_______________________________________________
dtn-interest mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/dtn-interest

---

From: Elwyn Davies <[email-masked]>
Date: Tue, 12 Jul 2011 13:21:29 +0100

Hi.

It is certainly true that short encounters could have a similar effect
to closely spaced encounters.  On the other hand it will probably only
make a big difference to the D.P. evolution if the encounters between
particular pairs of nodes are systematically shorter than those between
other pairs.  An occasional short encounter will get averaged out.

There is also a significant practical problem to factoring in individual
short encounters:  in almost all cases, you don't know an encounter is
going to be short until it has finished.  As it stands the D.P.s are
updated at the beginning of an encounter, so if you want to take into
account that *this* encounter was short immediately, then you have to
unwind and redo all the D.P. evolution that was done when the encounter
started - and also by then you have made forwarding decisions based on
the beginning of encounter updates.  Thus trying to factor in a single
short encounter is complicated and probably not worthwhile.

It might however be worthwhile trying to spot systematically short
encounters and apply some sort of correction relevant to those
encounters.  The downside is that it requires keeping a second value
(the mean length of encounter or possibly better the mean communication
opportunity capacity, i.e. length times effective bandwdith of
transfers) for each node that is encountered.  You could then tune
P_encounter to reflect the historical expectation of the effectivenes of
the encounters.

So far the real world experiments that we have done have mostly not run
into problems with opportunity capacity, but it is clearly possible that
this could be a problem. 

Note that trying this out (we are after all doing experimental
protocols!) would be quite simple - it does not affect the protocol
between nodes at all but is apllied locally in each node.  Please let us
know if you see any practical value (or have interesting simulation
results).

Regards,
Elwyn