Subject: Re: [dtn-interest] comments on draft-irtf-dtnrg-ecos
From: "Moore, Brad" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Fri, 26 Nov 2010 11:09:40 -0700
List-Id: Delay Tolerant Networking Interest List <dtn-interest.maillists.intel-research.net>

Lloyd Wood wrote:
> Reliable delivery or reliable as in error-free? The concepts are
> confused

I agree that there are multiple sub-properties that fall under the
"reliability" heading.
For example, error-free as in error-detecting, or error-correcting?

One approach would be to define specific flags for each of these
sub-attributes
so that a CL, such as the Saratoga CL (from what you describe), could
take advantage
of its richer feature set and address these attributes with precise
control.

Another approach, (the one that seems to be taken with the ecos draft)
is to
provide a very minimal set of flags that describe reliability in very
general terms,
and it is up to the CL, and the configuration of a Bundle Agent, to
determine how best to
interpret the general hint, and map to specific features of the CL.

I am not sure which of these two approaches is more appealing to me, but
in my opinion the
second approach needs more than just a single flag to represent a
reasonable set of semantics.
Some middle ground is needed.

The more control flags are added to the second approach, the more that
approach starts to
look like the first approach. My position right now is that adding one
more flag to the ecos
proposal is probably good enough to satisfy most needs, though I could
be convinced more towards the
first approach.

I agree that the terminology can be improved though. In fact, I think
"Streaming" can be misleading as well. I foresee the Streaming
flag being used in cases where the associated bundles are not
really part of a stream. Similarly, there can be cases there
streaming is occurring (possibly over TCP as you mention) 
where the Streaming flag may be undesirable.

First, what are the semantic attributes that might be associated with
setting the streaming flag?

 Setting the streaming flag might imply and affect some or all of the
following;
  1. Higher Speed - Lighter weight protocol sends data more quickly
  2. Lower bandwidth usage - Less data being sent 
  3. Lower delivery reliability - less or no resends
  4. Less error detection
  5. Less error correction
  6. Higher discardability - drop bundle if queue build up occurs, 
                             possibly forward only, instead of store and
forward
  7. Less persistence (possibly store in volatile memory rather than on
disk)

I see congestion control between the sender and the receiver 
(communicating round trip times for example) as being a configuration
of the CL as a function of the system contraints independent of the
setting of the streaming flag). Local congestion control (what I call
discardability)
however is more a function of the bundle agent than the CL.

If we set a reliability flag (or if we stuck with only the streaming
flag and this flag was not set), I see that would imply some or all of
the following;

  1. Lower Speed - Heavier weight protocol sends data at a slower rate
  2. Higher bandwidth usage - more data being sent 
  3. Higher delivery reliability - Resends >= 1
  4. More error detection (checksum?)
  5. More error correction (FEC?)
  6. Lower discardability - Avoid dropping bundle if at all possible
  7. More persistence Store on disk or non-volatile memory.

Note that these flags (both streaming, and reliability) can affect more
than just the selection
of CL. It may also affect queue management within the bundle agent for
example.

It's difficult to come up with a label for a single flag that describes
all of these effects.

Having two flags can make this easier, provided that the labels for the
flags are not
the boolean negation of each other. (eg. Streaming vs non-streaming, or
reliable vs non-reliable)

I think if the flags were labeled "Speed" (instead of "Streaming"), and
"Accuracy" (instead of "reliable"), then this would better capture the
semantics.

(Speed=> true, Accuracy=> false) seems to capture the effects associated
with the current streaming flag quite well.

Whereas;

(Speed=> false, Accuracy=> true) conversly seems to capture the effects
assocated with the other end of the spectrum.

As in real life, one cannot generally have both speed and accuracy
unless as some sort of compromise,
So;
(Speed=> true, Accuracy=> true) would be interpretted as being an
interest in both properties and represented as some middle ground
between the two, based on the available CL's, and their capabilities.

(Speed=> false, Accuracy=> false) indicates that neither of these
properties are of interest, and any decisions for the handling of a
bundle should be left to the default behaviours of the bundle agent and
CL.

Brad Moore

The information contained in this e-mail message is PRIVATE. It may contain confidential information and may be legally privileged. It is intended for the exclusive use of the addressee(s). If you are not the intended recipient, you are hereby notified that any dissemination, distribution or reproduction of this communication is strictly prohibited. If the intended recipient(s) cannot be reached or if a transmission problem has occurred, please notify the sender immediately by return e-mail and destroy all copies of this message. 
Thank you. 

From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Thu, 25 Nov 2010 21:47:46 +0000
Accept-Language: en-US, en-GB
acceptlanguage: en-US, en-GB
Subject: Re: [dtn-interest] comments on draft-irtf-dtnrg-ecos

Reliable delivery or reliable as in error-free? The concepts are confused below, and essentially repeating discussion on this list in 2007. Calling it a 'reliability bit' doesn't help.

> It's a bit difficult to imagine a case where one
> would want a bundle to be flagged as being reliable
> and discardable at the same time.

that's essentially what a UDP packet is - for reliable content.

The matrix can be written:
reliable delivery with resends - true/false
reliable content where errors in delivery are not tolerated (ie some effort is made to detect them) - true/false.
streaming - true/false (note that this is orthogonal to reliable delivery. TCP can provide reliable delivery and reliable content with streaming, though it comes with congestion control)
congestion control or not - true/false

These are all orthogonal. (The Saratoga specification can support the lot, but doesn't expose many of the options to bundling when acting as a convergence layer.)

Lloyd Wood
http://sat-net.com/L.Wood/dtn
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Moore, Brad [[email-masked]]
Sent: 25 November 2010 19:22
To: Burleigh, Scott C (313B); [email-masked]
Subject: Re: [dtn-interest] comments on draft-irtf-dtnrg-ecos

Thinking about discardability a bit more,

Another (perhaps better) alternative might be to just have the
reliability bit without the discardability bit.

If the streaming (unreliable) bit is set, that also could imply being
discardable.
It is after all, already unreliable.

It's a bit difficult to imagine a case where one would want a bundle to
be flagged as being reliable
and discardable at the same time.

Going back to the scenario where only TCP and UDP CL's are available at
a node.
This could lead to the following interpretations.

Streaming=True,  Reliable=False => UDP CL + discardable
Streaming=False, Reliable=True  => TCP CL + Not discardable
Streaming=True,  Reliable=True  => UDP CL + *Not* discardable
Streaming=False, Reliable=False => Use default CL

As before, if one had another CL that was lighter weight than TCP in
terms of bandwidth usage and reliability
then Streaming=True, Reliable=True might instead translate into
selecting that CL instead of UDP.

Brad

Content-class: urn:content-classes:message
Date: Thu, 25 Nov 2010 12:22:26 -0700
From: "Moore, Brad" <[email-masked]>
To: "Burleigh, Scott C (313B)" <[email-masked]>, <[email-masked]>
Subject: Re: [dtn-interest] comments on draft-irtf-dtnrg-ecos

Thinking about discardability a bit more, 

Another (perhaps better) alternative might be to just have the
reliability bit without the discardability bit.

If the streaming (unreliable) bit is set, that also could imply being
discardable.
It is after all, already unreliable.

It's a bit difficult to imagine a case where one would want a bundle to
be flagged as being reliable
and discardable at the same time.

Going back to the scenario where only TCP and UDP CL's are available at
a node.
This could lead to the following interpretations.

Streaming=True,  Reliable=False => UDP CL + discardable
Streaming=False, Reliable=True  => TCP CL + Not discardable
Streaming=True,  Reliable=True  => UDP CL + *Not* discardable
Streaming=False, Reliable=False => Use default CL

As before, if one had another CL that was lighter weight than TCP in
terms of bandwidth usage and reliability
then Streaming=True, Reliable=True might instead translate into
selecting that CL instead of UDP.

Brad

The information contained in this e-mail message is PRIVATE. It may contain confidential information and may be legally privileged. It is intended for the exclusive use of the addressee(s). If you are not the intended recipient, you are hereby notified that any dissemination, distribution or reproduction of this communication is strictly prohibited. If the intended recipient(s) cannot be reached or if a transmission problem has occurred, please notify the sender immediately by return e-mail and destroy all copies of this message. 
Thank you. 

From: Elwyn Davies <[email-masked]>
To: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 25 Nov 2010 17:01:08 +0000
Cc: Internet Research Steering Group <[email-masked]>, Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] [IRSG] Notification of IRSG poll start for draft-irtf-dtnrg-previous-hop-block

Hi Juergen.

We have now got proper IANA considerations in these docs.

Please check out
http://tools.ietf.org/html/draft-irtf-dtnrg-bundle-previous-hop-block-12.
Would you now be happy to change your vote to 'Yes' in the poll?

Regards,
Elwyn

On Fri, 2010-03-05 at 10:09 +0100, Juergen Schoenwaelder wrote:
> On Wed, Feb 24, 2010 at 05:34:04PM +0100, Elwyn Davies wrote:
>  
> > The DTN RG I-D: draft-irtf-dtnrg-previous-hop-block has
> > completed IRSG review.
> > The revised version of the I-D (Version 15) which incorporates the comments is
> > now available at:
> > http://tools.ietf.org/html/draft-irtf-dtnrg-previous-hop-block
> > John Wroclawski who has performed the IRSG review and the DTN RG have
> > approved the revised I-D to be progressed for publication.
> > 
> > The IRSG review is available from the IRTF tracker web page at:
> > http://trac.tools.ietf.org/group/irtf/trac/ticket/34
> > 
> > Please consider this email as the start of a four week IRSG poll. The
> > deadline for this poll is : Wednesday, March 24th, 2010.
> > 
> > Please use one of the poll responses defined below.
> > The possible poll responses are:
> > 
> >     o  'Ready to publish' -- requires a thorough read and reasonably
> >         detailed review
> > 
> >     o  'Not ready to publish' -- requires a thorough read, reasonably
> >        detailed review, and actionable comments.
> > 
> >     o  'No objection' -- I don't object if this document goes forward;
> >        I've read the document (perhaps quickly); I have some small
> >        comments which are not show stoppers; I don't have great
> >        expertise in the area.
> > 
> >     o  'Request more time to review' -- a commitment to provide a
> >        thorough review in a specified period of time.
> > 
> > The most relevant rule is that "At least two other IRSG members (besides the
> > one sponsoring the document) need to vote 'ready to publish' for the
> > document to move forward."
> 
> I believe the document (I checked -11 since there is no -17) is in a
> very good shape but I once again find the IANA considerations
> irritating.  Regardless whether this is a standards-track document or
> not, you really want to avoid clashes and creating a proper registry
> really is not a big deal.  While I believe the core of the document is
> ready to publish, I like to see this IANA registry issue worked out
> and hence I vote again 'Not ready to publish'.
> 
> /js
> 

From: Elwyn Davies <[email-masked]>
To: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 25 Nov 2010 16:59:02 +0000
Cc: Internet Research Steering Group <[email-masked]>, Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] [IRSG] Notification of IRSG poll start for draft-irtf-dtnrg-metadata-block

Hi Juergen.

We have now got proper IANA considerations in these docs, and
I think there was reasonable concensus on the authoritative 
reference for SDNVs previously.

Please check out
http://tools.ietf.org/html/draft-irtf-dtnrg-bundle-metadata-block-09.
Would you now be happy to change your vote to 'Yes' in the poll?

Regards,
Elwyn

On Thu, 2010-03-04 at 13:22 +0100, Juergen Schoenwaelder wrote:
> On Wed, Feb 24, 2010 at 05:32:19PM +0100, Elwyn Davies wrote:
> > Dear IRSG Memeber,
> > 
> > The DTN RG I-D: draft-irtf-dtnrg-metadata-block has
> > completed IRSG review.
> > The revised version of the I-D (Version 07) which incorporates the comments is
> > now available at:
> > http://tools.ietf.org/html/draft-irtf-dtnrg-metadata-block
> > Loxia Zhang who has performed the IRSG review and the DTN RG have
> > approved the revised I-D to be progressed for publication.
> > 
> > The IRSG review is available from the IRTF tracker web page at:
> > http://trac.tools.ietf.org/group/irtf/trac/ticket/33
> > 
> > Please consider this email as the start of a four week IRSG poll. The
> > deadline for this poll is : Wednesday, March 24th, 2010.
> > 
> > Please use one of the poll responses defined below.
> > The possible poll responses are:
> > 
> >     o  'Ready to publish' -- requires a thorough read and reasonably
> >         detailed review
> > 
> >     o  'Not ready to publish' -- requires a thorough read, reasonably
> >        detailed review, and actionable comments.
> > 
> >     o  'No objection' -- I don't object if this document goes forward;
> >        I've read the document (perhaps quickly); I have some small
> >        comments which are not show stoppers; I don't have great
> >        expertise in the area.
> > 
> >     o  'Request more time to review' -- a commitment to provide a
> >        thorough review in a specified period of time.
> > 
> > The most relevant rule is that "At least two other IRSG members (besides the
> > one sponsoring the document) need to vote 'ready to publish' for the
> > document to move forward."
> 
> I read the document and I vote "Note ready to publish" for two
> reasons:
> 
> First, the IANA considerations sections seems to be at odds with
> section 4.2 which requires registration of metadata types. The IANA
> Considerations section, however, only loosely talks about "we may
> consider creating a registry". I believe the document should actually
> create the relevant registries and establish the necessary procedures.
> 
> Second, I am wondering what the authoritative reference for SDNV
> encodings is going to be. This document refers to the bundle protocol
> specification but it is brought forward with a separate document
> defining SDNVs. This raises in fact the question whether
> draft-irtf-dtnrg-sdnv-06 is going to update RFC 5050, which has its
> own set of questions (an Informational document updating an
> Experimental document).
> 
> /js
> 
> PS: Someone needs to forward my comments to the DTNRG mailing list
>     since I am not subscribed and the mailer simply rejects my emails.
> 

From: Elwyn Davies <[email-masked]>
To: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 25 Nov 2010 16:40:07 +0000
Cc: Internet Research Steering Group <[email-masked]>, Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] [IRSG] Notification of IRSG poll start for draft-irtf-dtnrg-bundle-security

Hi, Juergen.

Just to confirm that these changes were eventually made in the security
draft.  Version 17
(http://tools.ietf.org/html/draft-irtf-dtnrg-bundle-security-17) has the
updated wording.

Please let us know if this is OK and you are still happy to vote 'Yes'
on this one.

Regards,
Elwyn

On Thu, 2010-03-25 at 00:39 -0700, Stephen Farrell wrote:
> Excellent. We'll post changes when we sort the IANA stuff,
> Thanks,
> S.
> 
> On 25 Mar 2010, at 00:34, Juergen Schoenwaelder <[email-masked] 
>  > wrote:
> 
> > On Thu, Mar 25, 2010 at 12:16:15AM +0100, Stephen Farrell wrote:
> >
> >>> a) I am wondering what the following statement means in practice:
> >>>
> >>>     Implementations SHOULD NOT be very strict in how they process  
> >>> X.509
> >>>     though, for example, it would probably not be correct to  
> >>> insist on
> >>>     Certificate Revocation List (CRL) checking in many DTN contexts.
> >>>
> >>>   This sentence sounds like asking for implementations to be lenient
> >>>   at the implementors choice while this is probably not a good idea
> >>>   security wise. For example, does this "SHOULD NOT be very strict"
> >>>   imply that implementations may accept wildcard certificates and do
> >>>   things as they might seem fit? There are many details when it  
> >>> comes
> >>>   to certificate processing and I believe this deserves a more
> >>>   detailed discussion and "SHOULD NOT be very strict in how they
> >>>   (implementations) process X.509" seems a too cheap way out.
> >>
> >> I guess we should restate the paragraph, its a bit vague. First  
> >> though,
> >> its not a security problem. RFC 5280 makes revocation checking  
> >> optional,
> >> and that's ok in some contexts. In our context we simply might not be
> >> able to access relevant CRLs or OCSP responders. How about if we
> >> rewrite it as follows:
> >>
> >>   RFC 5280 does not insist that implementations include revocation
> >>   checking. In the context of a DTN, it is reasonably likely that
> >>   some nodes would not be able to use revocation checking services
> >>   (either CRLs or OCSP) and deployments SHOULD take this into
> >>   account when planning any public key infrastructure to support
> >>   this specification.
> >
> > I am fine with the proposed new text. (However, I still believe that
> > the original text was a security problem since it said "SHOULD NOT be
> > very strict in how they process X.509" and the CRL checking was only
> > mentioned as "for example", leaving the door very wide open.)
> >
> >>> b) Should the text in the security considerations discuss the fact
> >>>   that notifications may be generated if security processing fails,
> >>>   thus potentially revealing something about where security
> >>>   processing takes place or providing a test mechanism?
> >>
> >> Sure. How about:
> >>
> >>   If a security target were to generate reports in the event that
> >>   some security validation step fails, then that might leak  
> >> information
> >>   about the internal structure or policies of the DTN containing the
> >>   security target. This is sometimes considered bad security practice
> >>   so SHOULD only be done with care.
> >
> > OK
> >
> >>> Should there
> >>>   be any text in the security considerations concerning any DoS
> >>>   possibilities due to heavy security processing caused by
> >>>   e.g. replays?
> >>
> >> In this case, I'd say not. I don't think BSP is different from any
> >> other crypto protocol in this respect. If there were a DTN specific
> >> issue, I'd have no problem adding something, but I don't think there
> >> is. (RFC 5050 has some mention of DoS in a DTN context generally as
> >> well.)
> >
> > It is not clear to me whether BSP is similar to other crypto protocols
> > in this respect. BSP is very flexible allowing hop-by-hop and
> > end-to-end security and pretty much anything in between and it is not
> > so clear to me whether the flexibility opens interesting new ways to
> > mount DoS attacks. But since this is not standards-track work, it is
> > probably OK to leave this out.
> >
> > With these changes in place, I am changing my vote to 'Ready to
> > publish'.
> >
> > /js
> >
> > -- 
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> > Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

Content-class: urn:content-classes:message
Date: Wed, 24 Nov 2010 11:08:43 -0700
From: "Moore, Brad" <[email-masked]>
To: "Burleigh, Scott C (313B)" <[email-masked]>, <[email-masked]>
Subject: Re: [dtn-interest] comments on draft-irtf-dtnrg-ecos

Thanks Scott for your comments,

Scott Burleigh wrote:
> 1) The more expressive QOS "hint" to the CL that you describe is
> exactly what the optional flow-label value in the ECOS block is
> intended to support.  The intent of the "streaming" flag, on the other
> hand, is very different: it addresses a very simple partitioning of
QOS
> space in a way that directly supports the vast bulk of DTN deployments
> contemplated to date.  If the flag is on (1), then the bundle protocol
> agent is requested to use unreliable transmission at the CL (in
> practice, either UDP or "green" LTP).  If the flag is off (0), then
the
> BPA is requested to use reliable transmission at the CL (in practice,
> either TCP or "red" LTP).
> 
> I think trying to overload that flag with a number of other yet-to-be-
> defined, hypothetical service features risks making it less useful,
> rather than more so.  I propose that we instead look at encoding those
> features in the flow label -- which can be made as large as necessary,
> without effect on the ECOS specification -- and maybe registering the
> flow label encoding with IANA.

Note my scheme wasn't so much to overload the existing streaming flag,
But instead to make use of some of the other unused bits to define some
additional flags, rather than add additional bytes to the payload, which
might be hard to justify for low bandwidth links. 

For the streaming flag, it still would essentially mean the same as 
it currently does. If it is on, then it is an indication to the 
bundle agent that the bundle should be delivered unreliably. If the
available CL's are UDP, and TCP, then this would suggest using the UDP
CL.

If it is off, then there is no need for unreliability, assuming there
are
no other significant contraints at a bundle agent, and given that in
general
reliable transmission is more desirable than unreliable transmission,
the
bundle agent would in this case choose the TCP CL. 
(If on the other hand, reliable transmission is viewed as being very
expensive
As might be the case for low bandwidth link, then the bundle agent might
still
choose the UDP CL)

The proposed reliability flag however, would provide a capability
similar to
the streaming flag, except expressing a desire for reliability instead
of unreliability.

If the reliability flag is on, then it is an indication to the 
bundle agent that the bundle should be delivered reliably. If the
available CL's are UDP, and TCP, then this would suggest using the TCP
CL.

If it is off, then there is no expressed need for reliability, assuming
there are
no other significant contraints at a bundle agent, and given that in
general
reliable transmission is more desirable than unreliable transmission,
the
bundle agent would in this case probably still choose the TCP CL. 
(If on the other hand, reliable transmission is viewed as being very
expensive
as might be the case for low bandwidth link, then the bundle agent might
instead
choose the UDP CL)

If both flags are set, then this suggests a compromise between
unreliability and
reliability is desired. If a CL exists that is viewed as being
moderately expensive
in terms of bandwidth, then that CL might be chosen. If the only
available choices
are UPD and TCP, then the bundle agent might choose either one,
depending on the
system constraints.

Similarly if both flags are not set, then there is no indication for
reliable or unreliable
transmission. In this case, the bundle agent would use the default CL,
which might also
depend on system constraints, and may result in the same choice as for
the case where
both flags are set if the only available choices are UDP and TCP. The
default CL 
does not necessarily have to be the same choice as the compromised  CL
choice.

I had considered using the flow label field for this purpose, but if
such use
ends up being something that is implementation defined and incompatible
with
other implementations, then one might as well just use the undefined
bits for
this purpose instead, since there is no cost in terms of bandwidth since
there is no
extra data being appended to the payload. Registering a flow label with
IANA might 
help address the implementation defined issue, but I think the
reliability flag and
the unreliability (streaming) flag naturally complement each other, and
it would be odd
to have one flag in a flags block, and another in a flow label block,
which may or may not
be respected by other implementations.

> 2) I think the combination of lifetime (time-to-live) and priority
> already fully expresses the discardability of a bundle in an objective
> and flexible way. 

I originally thought I could use lifetime to express discardability,
But came to the realization that lifetime and discardability are really 
unrelated.

Lifetime needs to remain with the original intent - how long is a bundle
relevant
In the system. It should not be used as an expectation on how long it
should
take for the message to be delivered. In practice, this cannot be known,
because
it is generally not known how many hops are needed to deliver a message
from the
source to the destination.

Consider GPS location updates that need to flood to all nodes. If one
tries to 
set the lifetime to prevent queue build and cause discarding based on
how long
it should take to deliver the bundle to the destination, you end up with
the
possibility that these GPS messages will never get delivered to far away
nodes,
with more than the expected number of hops.

In short, I have found that lifetime (time to live) is not useful for 
Discardability functionality.

> Lower priorities retard the progress of a bundle
> through the network, leaving them in buffers longer, and short
> lifetimes cause bundles to be discarded from the network's buffers
when
> -- in the judgment of their sources -- they are no longer worth trying
> to deliver.  When transmission resources are ample, everything gets
> delivered; when they are scarce, triage always favors the bundles
whose
> originators considered them to be most valuable.

I have also found that priority and discardability are also unrelated.
GPS location data may in fact be viewed as high priority data that
Should normally be sent ahead of most other messages in the system,
Yet can be discarded in the special case where a temporary spike in 
queue build up occurs at a particular node.

> In effect, priority and lifetime act to rank bundles in the order in
> which they will be discarded, wherever in the network they reside,
with
> considerable precision.  A discardability flag or label would not be
> nearly so fine-grained, effectively leaving bundle destruction
> decisions to the discretion of nodes that have little or no
> understanding of their value.

As already mentioned, neither priority or lifetime (nor their
combination)
are giving me the capability that I am looking for. A discardability
flag allows a 
bundle agent to discard bundles for any reason, so long as there 
is a reason, the bundle agent shouldn't need to have any deeper
understanding of the meaning of the discardability flag.

> 
> Data elision -- enabling later instrument readings to displace earlier
> ones that haven't been sent yet -- is a valuable function, but I think
> the right place to do it is at the originating application.  That's
> where the intelligence is located that will enable these decisions to
> be made accurately; this sort of application function awareness
doesn't
> belong in bundle routers.

The existing obsolesence block already provides this capability. The 
application might need to mark the bundle with obsolesence when it is
created,
but it then allows a bundle to be displaced at any intermediate bundle
agent node,
something that can't be done by the application. I am not suggesting any
new capabilities in this area.

Regards,
Brad

> -----Original Message-----
> From: [email-masked] [mailto:dtn-
> [email-masked]] On Behalf Of Moore,
Brad
> Sent: Thursday, November 18, 2010 9:38 AM
> To: [email-masked]
> Subject: [dtn-interest] comments on draft-irtf-dtnrg-ecos
> 
> I have some comments and questions regarding the ECOS extension block.
> 
> 1) The block defines a "streaming" bit flag that when set indicates
> that
> a bundle is to be
> delivered "by invoking an adapter for a convergence layer protocol
that
> does NOT perform
> retransmission of data lost in transit.  If the bundle protocol agent
> has no access to
> such a convergence layer adapter then this flag may be ignored, but in
> that case application
> data units may arrive out of transmission order at the destination
> (possibly degrading
> application performance) and/or transmission bandwidth may be wasted
on
> unnecessary
> retranssion, reducing the effective throughput of the network."
> 
> I am questioning whether one bit provides enough control over the
> reliability/bandwidth usage
> of delivering a bundle.
> 
> I can envisage a CL that is capable of trying harder than other CL's
to
> successfully deliver a bundle to the next node, (eg. By increasing FEC
> encoding, or higher levels of retries, or different ACKing schemes,
> etc)
> 
> The increased effort results in higher reliability, but at the expense
> of higher bandwidth.
> 
> A variation of this idea would allow for such a CL to support multiple
> levels of reliability, that can select an appropriate level of effort
> based on a hint, or indication in the ECOS block.
> 
> While I am not sure how many effort "levels" would generally be
useful,
> I think allowing for three levels (High, Medium, Low) would probably
> suffice, and would better meet the needs of a wider range of
> applications.
> Providing 3 or 4 reliability levels would require 2 bits instead of
one
> in the ECOS flags byte.
> This is a possibility because currently only 3 of the 8 bits are
> defined.
> 
> i.e., instead of 1 bit (streaming/low effort)
> 
> 0 - retransmission OK - more effort
> 1 - streaming - No retransmission - least effort
> 
> We could have;
> 
> 1 bit (streaming/low effort)
> 1 bit (reliable/high effort)
> 
> If only the streaming/low effort bit is set, this could indicate No
> Retranmission.
> 
> If only the high effort bit is set, this could indicate high
> reliability.
> 
> If both bits are set, then this indicates a compromise between levels
> of
> effort (Medium effort)
> 
> If neither bit is set, then the level of effort is unspecified, and
the
> behavior could be the same
> as if the ECOS block weren't present.
> 
> 
> 2) I think it would be useful to have another flag that indicates
> discardability.
> 
> The idea is that if the bundle is marked as being discardable, and
> there
> is queue build up at a Bundle Agent,
> then the bundle may be discarded (deleted).
> 
> For example, this would be appropriate for certain data that is
> periodic
> in nature, such as GPS location updates, where discarding an update is
> OK, if we know another update will be coming along shortly.
> 
> The obsolesence block could also be used to do this, but I think that
> is
> more appropriate for data that is not periodic in nature, eg. Status
> data. Since you don't know whether a newer update will be coming
along,
> it's a better strategy to have newer status updates replace older
> status
> updates.
> 
> The obsolesence block is higher cost though in terms of block
> length/bandwidth usage, which is why having a discardability bit in
the
> ECOS flags byte would be useful.
> 
> I see discardability as being independent of bundle priority.
> GPS location might be viewed as higher priority than normal messaging
> traffic, however may be more discardable than the normal messaging
> traffic.
> 
> It may even make sense to have two bits to indicate multiple levels of
> discardability,
> (eg. dscp assured forwarding (RFC 2597) defines three levels for
> drop-precedence which roughly corresponds to the discardability
> concept)
> 
> Should the ECOS block definition be extended to provide higher control
> for the level of sending effort, and
> to provide a discardability indication?
> 
> Brad Moore

The information contained in this e-mail message is PRIVATE. It may contain confidential information and may be legally privileged. It is intended for the exclusive use of the addressee(s). If you are not the intended recipient, you are hereby notified that any dissemination, distribution or reproduction of this communication is strictly prohibited. If the intended recipient(s) cannot be reached or if a transmission problem has occurred, please notify the sender immediately by return e-mail and destroy all copies of this message. 
Thank you. 

From: "Burleigh, Scott C (313B)" <[email-masked]>
To: "Moore, Brad" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 22 Nov 2010 14:30:23 -0800
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] comments on draft-irtf-dtnrg-ecos

Brad, a couple of thoughts:

1) The more expressive QOS "hint" to the CL that you describe is exactly what the optional flow-label value in the ECOS block is intended to support.  The intent of the "streaming" flag, on the other hand, is very different: it addresses a very simple partitioning of QOS space in a way that directly supports the vast bulk of DTN deployments contemplated to date.  If the flag is on (1), then the bundle protocol agent is requested to use unreliable transmission at the CL (in practice, either UDP or "green" LTP).  If the flag is off (0), then the BPA is requested to use reliable transmission at the CL (in practice, either TCP or "red" LTP).

I think trying to overload that flag with a number of other yet-to-be-defined, hypothetical service features risks making it less useful, rather than more so.  I propose that we instead look at encoding those features in the flow label -- which can be made as large as necessary, without effect on the ECOS specification -- and maybe registering the flow label encoding with IANA.

2) I think the combination of lifetime (time-to-live) and priority already fully expresses the discardability of a bundle in an objective and flexible way.  Lower priorities retard the progress of a bundle through the network, leaving them in buffers longer, and short lifetimes cause bundles to be discarded from the network's buffers when -- in the judgment of their sources -- they are no longer worth trying to deliver.  When transmission resources are ample, everything gets delivered; when they are scarce, triage always favors the bundles whose originators considered them to be most valuable.

In effect, priority and lifetime act to rank bundles in the order in which they will be discarded, wherever in the network they reside, with considerable precision.  A discardability flag or label would not be nearly so fine-grained, effectively leaving bundle destruction decisions to the discretion of nodes that have little or no understanding of their value.

Data elision -- enabling later instrument readings to displace earlier ones that haven't been sent yet -- is a valuable function, but I think the right place to do it is at the originating application.  That's where the intelligence is located that will enable these decisions to be made accurately; this sort of application function awareness doesn't belong in bundle routers.

Scott

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Moore, Brad
Sent: Thursday, November 18, 2010 9:38 AM
To: [email-masked]
Subject: [dtn-interest] comments on draft-irtf-dtnrg-ecos

I have some comments and questions regarding the ECOS extension block.

1) The block defines a "streaming" bit flag that when set indicates that
a bundle is to be
delivered "by invoking an adapter for a convergence layer protocol that
does NOT perform
retransmission of data lost in transit.  If the bundle protocol agent
has no access to 
such a convergence layer adapter then this flag may be ignored, but in
that case application 
data units may arrive out of transmission order at the destination
(possibly degrading 
application performance) and/or transmission bandwidth may be wasted on
unnecessary 
retranssion, reducing the effective throughput of the network."

I am questioning whether one bit provides enough control over the
reliability/bandwidth usage
of delivering a bundle.

I can envisage a CL that is capable of trying harder than other CL's to
successfully deliver a bundle to the next node, (eg. By increasing FEC
encoding, or higher levels of retries, or different ACKing schemes, etc)

The increased effort results in higher reliability, but at the expense
of higher bandwidth.

A variation of this idea would allow for such a CL to support multiple
levels of reliability, that can select an appropriate level of effort
based on a hint, or indication in the ECOS block.

While I am not sure how many effort "levels" would generally be useful,
I think allowing for three levels (High, Medium, Low) would probably
suffice, and would better meet the needs of a wider range of
applications.
Providing 3 or 4 reliability levels would require 2 bits instead of one
in the ECOS flags byte.
This is a possibility because currently only 3 of the 8 bits are
defined.

i.e., instead of 1 bit (streaming/low effort)

0 - retransmission OK - more effort
1 - streaming - No retransmission - least effort

We could have;

1 bit (streaming/low effort)
1 bit (reliable/high effort)

If only the streaming/low effort bit is set, this could indicate No
Retranmission.

If only the high effort bit is set, this could indicate high
reliability.

If both bits are set, then this indicates a compromise between levels of
effort (Medium effort)

If neither bit is set, then the level of effort is unspecified, and the
behavior could be the same
as if the ECOS block weren't present.

2) I think it would be useful to have another flag that indicates
discardability.

The idea is that if the bundle is marked as being discardable, and there
is queue build up at a Bundle Agent,
then the bundle may be discarded (deleted).

For example, this would be appropriate for certain data that is periodic
in nature, such as GPS location updates, where discarding an update is
OK, if we know another update will be coming along shortly.

The obsolesence block could also be used to do this, but I think that is
more appropriate for data that is not periodic in nature, eg. Status
data. Since you don't know whether a newer update will be coming along,
it's a better strategy to have newer status updates replace older status
updates.

The obsolesence block is higher cost though in terms of block
length/bandwidth usage, which is why having a discardability bit in the
ECOS flags byte would be useful.

I see discardability as being independent of bundle priority.
GPS location might be viewed as higher priority than normal messaging
traffic, however may be more discardable than the normal messaging
traffic.

It may even make sense to have two bits to indicate multiple levels of
discardability, 
(eg. dscp assured forwarding (RFC 2597) defines three levels for
drop-precedence which roughly corresponds to the discardability concept)

Should the ECOS block definition be extended to provide higher control
for the level of sending effort, and 
to provide a discardability indication?

Brad Moore

The information contained in this e-mail message is PRIVATE. It may contain confidential information and may be legally privileged. It is intended for the exclusive use of the addressee(s). If you are not the intended recipient, you are hereby notified that any dissemination, distribution or reproduction of this communication is strictly prohibited. If the intended recipient(s) cannot be reached or if a transmission problem has occurred, please notify the sender immediately by return e-mail and destroy all copies of this message. 
Thank you. 

_______________________________________________
dtn-interest mailing list
[email-masked]
http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Mon, 22 Nov 2010 22:48:32 +0200
From: Sotirios Diamantopoulos <[email-masked]>
To: [email-masked], [email-masked]
Subject: [dtn-interest] BCFIC 2011 - "Space/Earth Delay/Disruption Tolerant Networking" special session: Extended Deadline, December 20

CFP Deadline extended to December 20, 2010!

---------------------------------------------------------------------------
*** Our apologies if you receive multiple copies of this CFP ***
---------------------------------------------------------------------------

Baltic Congress on Future Internet Communications (BCFIC Riga 2011)

Special session on "Space/Earth Delay/Disruption Tolerant Networking"

Riga, Latvia

February, 16-18, 2011

"Space/Earth Delay/Disruption Tolerant Networking" special session, held
in conjunction with the Baltic Conference on Future Internet
Communications, on February 2011 at Riga, Latvia (BCFIC Riga 2011),
seeks novel ideas in the form of preliminary or work-in-progress results
as well as mature research papers for Delay-/Disruption Tolerant
Networks. Work-in-progress papers are appropriate indeed for the
session. Such papers could be further developed with more mature results
and submitted to the relevant special session of the Journal of Internet
Engineering, which is scheduled for April 2011. Topics include but are
not limited to:

* DTN Routing

* Reliability mechanisms

* Congestion and Storage Congestion Control

* Resource Sharing in DTN environments

* Network Coding techniques for DTNs

* Application Development

* Network management

* Error and Flow Control

* Privacy and Security of Information in DTNs

* Naming/Addressing and interoperability issues with the Internet
architecture

* Experiences and Measurements from DTN testbeds

* Performance Evaluation and Metrics for DTN Research

* Performance and Design Tradeoffs for DTN Algorithms and Protocols

* DTN Architectures:

    - Satellite Communications

    - Deep-space Communications

    - Underwater Communications

    - Connectivity in Developing Countries

    - Communication in Public and Private Transport Vehicles

It should also be noted that:

- A selection of the best papers will be invited for special issues in
the Journal of Internet Engineering and Elsevier Adhoc Networks Journal.

- BCFIC Riga 2011 proceedings will be published in IEEE Xplore
(approved) and indexed in the correspondent databases (e.g. EI-index and
others).

- BCFIC Riga 2011 is Technically Co-Sponsored by IEEE Latvia (approved).

Paper-submission Deadline: December 20, 2010

Acceptance Notification: January 5, 2011

Camera Ready: January 12, 2011

Session Organizers:

- Vassilis Tsaoussidis, Professor, Department of Electrical Engineering,
Democritus University of Thrace, Greece

- Efthymios Koutsogiannis, PhD Candidate

- Sotirios Diamantopoulos, PhD Candidate

Kind Regards,

Sotirios Diamantopoulos

Internetworked Systems Lab, Democritus University of Thrace
http://intersys.ee.duth.gr

Date: Mon, 22 Nov 2010 19:44:31 +0100 (CET)
From: Aline Viana <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] CFP: MOBILITY 2011

------=_Part_1373810_2012147162.1290451471895
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

[We apologize in advance if you receive multiple copies of this message] =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D CALL FOR PAPERS MOBILITY 2011=20

The First International Conference on Mobile Services, Resources, and Users=
=20

http://www.iaria.org/conferences2011/MOBILITY11.html=20

July 17-22, 2011 - Bournemouth, UK, under DataSys 2011=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D SCOPE=
:=20

Users increasingly rely on devices in different mobile scenarios and situat=
ions. "Everything is mobile", and mobility is now ubiquitous. Services are =
supported in mobile environments, through smart devices and enabling softwa=
re. While there are well known mobile services, the extension to mobile com=
munities and on-demand mobility requires appropriate mobile radios, middlew=
are and interfacing. Mobility management becomes more complex, but is essen=
tial for every business. Mobile wireless communications, including vehicula=
r technologies bring new requirements for ad hoc networking, topology contr=
ol and interface standardization.=20

MOBILITY 2011 starts a series of events dedicated to mobility-at-large, dea=
ling with challenges raised by mobile services and applications considering=
 user, device and service mobility.=20

We welcome technical papers presenting research and practical results, posi=
tion papers addressing the pros and cons of specific proposals, such as tho=
se being discussed in the standard fora or in industry consortia, survey pa=
pers addressing the key problems and solutions on any of topics, short pape=
rs on work in progress, workshops and panel proposals.=20

Industrial presentations are not subject to these constraints. We expect sh=
ort and long presentations that express industrial position and status. Tut=
orials on specific related topics and panels on challenging areas are encou=
raged.=20

TOPICS OF INTEREST:=20

The topics suggested by the conference can be discussed in term of concepts=
, state of the art, research, standards, implementations, running experimen=
ts, applications, and industrial case studies. Authors are invited to submi=
t complete unpublished papers, which are not under review in any other conf=
erence or journal in the following, but not limited to, topic areas. All tr=
acks are open to both research and industry contributions.=20

All tracks are open to both research and industry contributions.=20

Mobile architectures, mechanisms, protocols=20

--------------------------------------------=20

Mobility and wireless=20

Mobility enabling protocols=20

Mobile software=20

Service composition in mobile environments=20

Knowledge and service discovery in mobile environments=20

On-demand mobility=20

User presence in mobile environments=20

Replication in mobile environments=20

Middleware for mobile environments=20

Internet and mobility=20

Software architecture for mobile applications=20

Mobile networking and management=20

---------------------------------=20

Fundamentals of mobile networks=20

Mobile-Fixed interworking=20

Heterogenous networks=20

Beyond IMT-A=20

Mobile network virtualization=20

Femtocells and relays=20

Mobile cells=20

Mobile network sharing and network access=20

Self-management of mobile networks=20

Mobility management=20

Access control in mobile environments=20

Advanced roaming concepts=20

Mobile network edge-based service delivery platforms=20

Mobile content delivery networks=20

Mobile peer-to-peer systems=20

Mobile VPNs=20

Quality of experience in mobile networks=20

Mobile devices and services=20

----------------------------=20

Smart mobile devices=20

Embedded mobile=20

Sensors and mobiles=20

Mobile media, mobile content=20

Mobile applications (mobile learning, mobile healthcare, etc.)=20

Mobile games=20

Mobile business=20

Mobile Web applications=20

Apps versus Web=20

Novel software concepts for mobile services=20

Mobile- and micro payment=20

mCommerce=20

Mobile prosumers and interfaces=20

--------------------------------=20

User interaction and mobility=20

Mobile communities=20

Mobile Web interfaces and interaction techniques=20

Implementations and experimental mobile systems=20

Mobile Web=20

Mobile search and advertising=20

Mobile Internet of Things=20

--------------------------=20

Future mobile Internet=20

Internet of Things=20

Machine to Machine, People, Business (M2x)=20

Online=20

Smart Homes=20

Smart Cities=20

Vehicular mobile technology=20

----------------------------=20

Architectures and platforms=20

Vehicular ad hoc networks=20

Vehicular routing metrics and supporting protocols=20

Mobility management and topology control=20

Standardization of vehicular networks=20

User aspects=20

Business enablers=20

Challenges in mobile environments=20

----------------------------------=20

Security and privacy environments=20

Protection and safety of distributed mobile data=20

Context-aware mobility and privacy=20

Mobile emergency communication and public safety=20

Location-based services=20

Micro-payments=20

Accuracy and preciseness in localizing mobile entities=20

INSTRUCTIONS FOR THE AUTHORS:=20

Authors of selected papers will be invited to submit extended versions to o=
ne of the IARIA Journals .=20

Publisher: XPS (Xpert Publishing Services)=20
Archived: ThinkMind TM Digital Library (free access)=20
Submitted for indexing:=20
- ISI Thompson Conference Proceedings Citation Index (CPCI)=20
- Elsevier's EI Compendex Database, EI=E2=80=99s Engineering Information In=
dex=20
- DBLP, IET INSPEC, and other relevant specialized indexes.=20
- Other indexes are being considered=20

Important dates:=20

----------------=20

Submission (full paper) March 1, 2011=20

Notification April 10, 2011=20

Registration April 25, 2011=20

Camera ready April 28, 2011=20

Only .pdf or .doc files will be accepted for paper submission. All received=
 papers will be acknowledged via an automated system.=20

Final author manuscripts will be 8.5" x 11", not exceeding 6 pages; max 4 e=
xtra pages allowed at additional cost. The formatting instructions can be f=
ound on the Instructions page. Helpful information for paper formatting can=
 be found on the here.=20

Your paper should also comply with the additional editorial rules.=20

Once you receive the notification of paper acceptance, you will be provided=
 by the publisher an online author kit with all the steps an author needs t=
o follow to submit the final version. The author kits URL will be included =
in the letter of acceptance.=20

Poster Forum:=20

-------------=20

Posters are welcome. Please submit the contributions following the instruct=
ions for the regular submissions using the "Submit a Paper" button and sele=
cting the contribution type as poster. Submissions are expected to be 6-8 s=
lide deck. Posters will not be published in the Proceedings. One poster wit=
h all the slides together should be used for discussions. Presenters will b=
e allocated a space where they can display the slides and discuss in an inf=
ormal manner. The poster slide decks will be posted on the IARIA site.=20

For more details, see the Poster Forum explanation page.=20

Work in Progress:=20

----------------=20

Work-in-progress contributions are welcome. Please submit the contributions=
 following the instructions for the regular submissions using the "Submit a=
 Paper" button and selecting the contribution type as work in progress. Aut=
hors should submit a four-page (maximum) text manuscript in IEEE double-col=
umn format including the authors' names, affiliations, email contacts. Cont=
ributors must follow the conference deadlines, describing early research an=
d novel skeleton ideas in the areas of the conference topics. The work will=
 be published in the conference proceedings.=20

For more details, see the Work in Progress explanation page=20

Technical marketing/business/positioning presentations:=20

-------------------------------------------------------=20

The conference initiates a series of business, technical marketing, and pos=
itioning presentations on the same topics. Speakers must submit a 10-12 sli=
de deck presentations with substantial notes accompanying the slides, in th=
e .ppt format (.pdf-ed). The slide deck will not be published in the confer=
ence=E2=80=99s CD Proceedings. Presentations' slide decks will be posted on=
 the IARIA's site. Please send your presentations to [email-masked].=20

Tutorials:=20

----------=20

Tutorials provide overviews of current high interest topics. Proposals shou=
ld be for three hour tutorials. Proposals must contain the title, the summa=
ry of the content, and the biography of the presenter(s). The tutorials' sl=
ide decks will be posted on the IARIA's site. Please send your proposals to=
 [email-masked]=20

Panel proposals:=20

----------------=20

The organizers encourage scientists and industry leaders to organize dedica=
ted panels dealing with controversial and challenging topics and paradigms.=
 Panel moderators are asked to identify their guests and manage that their =
appropriate talk supports timely reach our deadlines. Moderators must speci=
fically submit an official proposal, indicating their background, panelist =
names, their affiliation, the topic of the panel, as well as short biograph=
ies. The panel's slide deck will be posted on the IARIA's site.=20

For more information, [email-masked]=20

Workshop proposals:=20

-------------------=20

We welcome workshop proposals on issues complementary to the topics of this=
 conference. Your requests should be forwarded to [email-masked].=20

GENERAL CHAIR=20

Josef Noll, University of Oslo & Movation, Norway=20

TECHNICAL PROGRAM COMMITTEE=20

Ramon Aguero Calvo, University of Cantabria, Italy=20
Nazim Agoulmine, University of Evry, France=20
Ioannis Anagnostopoulos, University of Central Greece - Lamia, Greece=20
Faouzi Bader, Centre Tecnologic de Telecomunicacions de Catalunya (CTTC), S=
pain=20
Payam M. Barnaghi, University of Surrey, United Kingdom=20
Sonia Buchegger, KTH - Stockholm, Sweden=20
Filipe Cabral Pinto, Telecom Inova=C3=A7=C3=A3o S.A., Portugal=20
Jian-Nong Cao, Hong Kong Polytechnic University, Hong Kong=20
Aline Carneiro Viana, INRIA Saclay - Ile de France - Orsay, France=20
Mohammad Mushfiqur Chowdhury, University of Oslo, Norway=20
Luis M. Correia, IST - Technical University of Lisbon, Portugal=20
Klaus David, University of Kassel, Germany=20
Kevin Deng, Jilin University, China=20
Marco Fiore, INSA Lyon, INRIA, France=20
Gianluca Franchino, CEIICP - Scuola Superiore Sant'Anna - Pisa, Italy=20
Joern Franke, SAP Research Center - Sophia Antipolis, France=20
Rosario Garrido Cantos, University of Castilla-La-Mancha - Albacete, Spain=
=20
Kamrul Hassan, Bangladesh University of Engineering and Technology, Banglad=
esh=20
Peizhao Hu, NICTA, Australia=20
Jiun-Long Huang, National Chiao Tung University, Taiwan=20
Pekka J=C3=A4ppinen. Lappeenranta University of Technology, Finland=20
Eduardo Juarez, Universidad Politecnica de Madrid (UPM), Spain=20
Vana Kalogeraki, Athens University of Economics and Business, Greece=20
Vasileios Karyotis, National Technical University of Athens (NTUA), Greece=
=20
In-Young Ko, Korea Advanced Institute of Science and Technology (KAIST), Ko=
rea=20
Brent Lagesse, Oak Ridge National Laboratory, USA=20
Juhani Latvakoski, VTT, Finland=20
Frank Yong Li, University Agder, Norway=20
Seng Loke, La Trobe University, Australia=20
Xun Luo, Qualcomm Inc. - San Diego, USA=20
Satya Prasad Majumder, Bangladesh University of Engineering and Technology,=
 Bangladesh=20
Behrouz Maham, UNIK-University Graduate Center, Norway=20
Torleiv Maseng, FFI, Norway=20
Constandinos Mavromoustakis, University of Nicosia, Cyprus=20
Sandro Moiron, University of Essex, UK=20
Luis Mu=C3=B1oz, University of Cantabria - Santander, Spain=20
Masayuki Murata, Osaka University, Japan=20
Norbert Niebert, Ericsson Eurolabs, Germany=20
Josef Noll, University of Oslo & Movation, Norway=20
Jordi Ortiz Murillo, University of Murcia, Spain=20
Knut =C3=98vsthus, Bergen University College, Norway=20
Sangheon Pack, Korea University, Korea=20
Paolo Pagano, Consorzio Nazionale Interuniversitario per le Telecomunicazio=
ni - Pisa, Italy=20
Marko Palviainen, VTT, Finland=20
Riccardo Pascotto, T-Labs, Germany=20
Prashant Pillai, University of Bradford, UK=20
George C. Polyzos, Athens University of Economics and Business, Greece=20
Stefan Poslad, Queen Mary University of London, UK=20
Neeli R. Prasad, Aalborg University, Denmark=20
Daniele Puccinelli, University of Applied Sciences of Southern Switzerland =
(SUPSI), Switzerland=20
Frank Reichert, University of Agder (UiA) - Grimstad, Norway=20
Andreas Reinhardt, Technische Universit=C3=A4t Darmstadt (TU Darmstadt), Ge=
rmany=20
Daniele Riboni, Universit=C3=A0 degli Studi di Milano, Italy=20
Joel Rodr=C3=ACgues, University of Beira Interior - Covilh=C3=A3 / Institut=
o de Telecomunica=C3=A7=C3=B5es, Portugal=20
Chunming Rong, University of Stavanger, Norway=20
Giancarlo Ruffo, University of Turin, Italy=20
Sicari Sabrina, Universita degli studi dell'Insubria, Italy=20
Farzad Salim, Queensland University of Technology, Australia=20
Stefan Schmid, TU Berlin, Germany=20
Behrooz Shirazi, Washington State University, USA=20
Andrey Somov, CREATE-NET, Italy=20
Xiang Song, Microsoft, USA=20
Stephan Steglich, FOKUS Fraunhofer, Germany=20
Masashi Sugano, Osaka Prefecture University, Japan=20
Mikko Uitto, VTT Technical Research Centre of Finland, Finland=20
Amit Vasudevan, Carnegie Mellon University, USA=20
Matthias Wagner, DOCOMO Euro-Labs, Germany=20
Erik Wilde, University of California at Berkeley, USA=20
Chansu Yu, Cleveland State University, USA=20
Zhiwen Yu, Northwestern Polytechnical University, China=20
Annie Zhao, GM Global R&D Center, USA=20

------=_Part_1373810_2012147162.1290451471895
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D'text/css'>p { margin: 0; }</style></head><body><=
div style=3D'font-family: Times New Roman; font-size: 12pt; color: #000000'=
><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:View>Normal</w:View>
  <w:Zoom>0</w:Zoom>
  <w:HyphenationZone>21</w:HyphenationZone>
  <w:PunctuationKerning/>
  <w:ValidateAgainstSchemas/>
  <w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>
  <w:IgnoreMixedContent>false</w:IgnoreMixedContent>
  <w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText>
  <w:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
   <w:DontGrowAutofit/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:LatentStyles DefLockedState=3D"false" LatentStyleCount=3D"156">
 </w:LatentStyles>
</xml><![endif]--><!--[if !mso]><object
 classid=3D"clsid:38481807-CA0E-42D2-BF39-B33AF135CC4D" id=3Dieooui></objec=
t>
<style>
st1\:*{behavior:url(#ieooui) }
</style>
<![endif]--><!--[if gte mso 10]>
<style>
 /* Style Definitions */
 table.MsoNormalTable
=09{mso-style-name:"Tableau Normal";
=09mso-tstyle-rowband-size:0;
=09mso-tstyle-colband-size:0;
=09mso-style-noshow:yes;
=09mso-style-parent:"";
=09mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
=09mso-para-margin:0cm;
=09mso-para-margin-bottom:.0001pt;
=09mso-pagination:widow-orphan;
=09font-size:10.0pt;
=09font-family:"Times New Roman";
=09mso-ansi-language:#0400;
=09mso-fareast-language:#0400;
=09mso-bidi-language:#0400;}
</style>
<![endif]--><pre style=3D"text-align: justify;"><span style=3D"" lang=3D"EN=
-GB">[We apologize in advance if you receive multiple copies of this messag=
e]</span></pre><span style=3D"" lang=3D"EN-GB">=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</span><pre =
style=3D"text-align: justify;"><span style=3D"" lang=3D"EN-GB"><span style=
=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp; </span>CALL FOR PAPERS</span></pre><pre style=3D"text-align: justify=
;"><span style=3D"" lang=3D"EN-GB"><span style=3D"">&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>MOBILITY =
2011</span></pre>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB"><span styl=
e=3D""></span><span style=3D""> </span><span style=3D"">&nbsp;&nbsp;&nbsp;&=
nbsp;</span><span style=3D"">&nbsp;&nbsp;</span><span style=3D""> </span>Th=
e First International Conference on<span style=3D""></span><span style=3D""=
></span><span style=3D""> </span>Mobile
Services, Resources, and Users </span></p>

<p class=3D"MsoNormal" style=3D"margin-left: 35.4pt; text-align: justify; t=
ext-indent: 35.4pt;"><span style=3D"font-size: 10pt; font-family: &quot;Cou=
rier New&quot;;"><a href=3D"http://www.iaria.org/conferences2011/MOBILITY11=
.html"><span style=3D"" lang=3D"EN-GB">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; http:=
//www.iaria.org/conferences2011/MOBILITY11.html</span></a></span><span styl=
e=3D"font-size: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB"=
></span></p>

<p class=3D"MsoNormal" style=3D"margin-left: 70.8pt; text-align: justify;">=
<span style=3D"font-size: 10pt; font-family: &quot;Courier New&quot;;" lang=
=3D"EN-GB">&nbsp;</span></p>

<p class=3D"MsoNormal" style=3D"margin-left: 70.8pt; text-align: justify;">=
<span style=3D"font-size: 10pt; font-family: &quot;Courier New&quot;;" lang=
=3D"EN-GB">&nbsp;&nbsp;&nbsp;&nbsp; July 17-22, 2011 - Bournemouth,
 UK, under
DataSys 2011 <br></span></p>

<pre style=3D"text-align: justify;"><span style=3D"" lang=3D"EN-GB">=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</span></pre=
><pre style=3D"text-align: justify;"><span style=3D"" lang=3D"EN-GB">SCOPE:=
 <br></span></pre>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Users
increasingly rely on devices in different mobile scenarios and situations.
"Everything is mobile", and mobility is now ubiquitous. Services are
supported in mobile environments, through smart devices and enabling softwa=
re.
While there are well known mobile services, the extension to mobile communi=
ties
and on-demand mobility requires appropriate mobile radios, middleware and
interfacing. Mobility management becomes more complex, but is essential for
every business. Mobile wireless communications, including vehicular
technologies bring new requirements for ad hoc networking, topology control=
 and
interface standardization.</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">MOBILITY
2011 starts a series of events dedicated to mobility-at-large, dealing with
challenges raised by mobile services and applications considering user, dev=
ice
and service mobility. </span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">&nbsp;</sp=
an></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">We
welcome technical papers presenting research and practical results, positio=
n
papers addressing the pros and cons of specific proposals, such as those be=
ing
discussed in the standard fora or in industry consortia, survey papers addr=
essing
the key problems and solutions on any of topics, short papers on work in
progress, workshops and panel proposals.</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Industrial
presentations are not subject to these constraints. We expect short and lon=
g presentations
that express industrial position and status. Tutorials on specific related
topics and panels on challenging areas are encouraged.</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">&nbsp;</sp=
an></p>

<pre style=3D"text-align: justify;"><span style=3D"" lang=3D"EN-GB">TOPICS =
OF INTEREST:</span><span style=3D"font-size: 10pt; font-family: &quot;Couri=
er New&quot;;" lang=3D"EN-GB"> <br></span></pre>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">The
topics suggested by the conference can be discussed in term of concepts, st=
ate
of the art, research, standards, implementations, running experiments, appl=
ications,
and industrial case studies. Authors are invited to submit complete unpubli=
shed
papers, which are not under review in any other conference or journal in th=
e
following, but not limited to, topic areas. All tracks are open to both
research and industry contributions.</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">&nbsp;</sp=
an></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">All
tracks are open to both research and industry contributions.</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">&nbsp;</sp=
an></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Mobile
architectures, mechanisms, protocols</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">----------=
----------------------------------</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Mobility
and wireless</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Mobility
enabling protocols</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Mobile
software</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Service
composition in mobile environments</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Knowledge
and service discovery in mobile environments</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">On-demand
mobility</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">User
presence in mobile environments</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Replicatio=
n
in mobile environments</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Middleware
for mobile environments</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Internet
and mobility</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Software
architecture for mobile applications</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">&nbsp;</sp=
an></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Mobile
networking and management</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">----------=
-----------------------</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Fundamenta=
ls
of mobile networks</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Mobile-Fix=
ed
interworking</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Heterogeno=
us
networks</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Beyond
IMT-A</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Mobile
network virtualization</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Femtocells
and relays</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Mobile
cells</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Mobile
network sharing and network access</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Self-manag=
ement
of mobile networks</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Mobility
management</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Access
control in mobile environments</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Advanced
roaming concepts</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Mobile
network edge-based service delivery platforms</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Mobile
content delivery networks</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Mobile
peer-to-peer systems</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Mobile
VPNs</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Quality
of experience in mobile networks</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">&nbsp;</sp=
an></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"FR">Mobile device=
s and
services</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"FR">-------------=
---------------</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"FR">Smart mobile =
devices</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"FR">Embedded mobi=
le</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"FR">Sensors and m=
obiles</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"FR">Mobile media,=
 mobile
content</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"FR">Mobile applic=
ations
(mobile learning, mobile healthcare, etc.)</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"FR">Mobile games<=
/span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"FR">Mobile busine=
ss</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"FR">Mobile Web ap=
plications</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Apps
versus Web</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Novel
software concepts for mobile services</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Mobile-</s=
pan><span style=3D"font-size: 10pt; font-family: &quot;Courier New&quot;;" =
lang=3D"EN-GB"> and micro payment</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">mCommerce<=
/span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">&nbsp;</sp=
an></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Mobile
prosumers and interfaces</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">----------=
----------------------</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">User
interaction and mobility</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Mobile
communities</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Mobile
Web interfaces and interaction techniques</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Implementa=
tions
and experimental mobile systems</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Mobile
Web</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Mobile
search and advertising</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">&nbsp;</sp=
an></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Mobile
Internet of Things</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">----------=
----------------</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Future
mobile Internet</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Internet
of Things</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Machine
to Machine, People, Business (M2x)</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Online</sp=
an></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Smart
Homes</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Smart
Cities</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">&nbsp;</sp=
an></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Vehicular
mobile technology</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">----------=
------------------</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Architectu=
res
and platforms</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Vehicular
ad hoc networks</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Vehicular
routing metrics and supporting protocols</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Mobility
management and topology control</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Standardiz=
ation
of vehicular networks</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">User
aspects</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Business
enablers</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">&nbsp;</sp=
an></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Challenges
in mobile environments</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">----------=
------------------------</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Security
and privacy environments</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Protection
and safety of distributed mobile data</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Context-aw=
are
mobility and privacy</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Mobile
emergency communication and public safety</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Location-b=
ased
services</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Micro-paym=
ents</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Accuracy
and preciseness in localizing mobile entities</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">&nbsp;</sp=
an></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">&nbsp;</sp=
an></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">INSTRUCTIO=
NS
FOR THE AUTHORS:</span></p><p class=3D"MsoNormal" style=3D"text-align: just=
ify;"><span style=3D"font-size: 10pt; font-family: &quot;Courier New&quot;;=
" lang=3D"EN-GB"><br></span></p>

<p><span style=3D"font-size: 10pt; font-family: &quot;Courier New&quot;;" l=
ang=3D"EN-GB">Authors of selected papers will be invited to submit
extended versions to one of the </span><span style=3D"font-size: 10pt; font=
-family: &quot;Courier New&quot;;"><a href=3D"http://www.iariajournals.org/=
"><span style=3D"" lang=3D"EN-GB">IARIA Journals</span></a></span><span sty=
le=3D"font-size: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB=
">.</span></p>

<p><span style=3D"font-size: 10pt; font-family: &quot;Courier New&quot;;" l=
ang=3D"EN-GB">Publisher: </span><span style=3D"font-size: 10pt; font-family=
: &quot;Courier New&quot;;"><a href=3D"http://www.xpertps.com/" target=3D"_=
blank"><span style=3D"" lang=3D"EN-GB">XPS (Xpert Publishing Services)</spa=
n></a></span><span style=3D"font-size: 10pt; font-family: &quot;Courier New=
&quot;;" lang=3D"EN-GB"><br>
Archived: </span><span style=3D"font-size: 10pt; font-family: &quot;Courier=
 New&quot;;"><a href=3D"http://www.thinkmind.org/" target=3D"_blank"><span =
style=3D"" lang=3D"EN-GB">ThinkMind<sup>TM</sup> Digital Library</span></a>=
</span><span style=3D"font-size: 10pt; font-family: &quot;Courier New&quot;=
;" lang=3D"EN-GB"> (free access)<br>
Submitted for indexing:<br>
- ISI Thompson Conference Proceedings Citation Index (CPCI)<br>
- Elsevier's EI Compendex Database, EI=E2=80=99s Engineering Information In=
dex<br>
- DBLP, IET INSPEC, and other relevant specialized indexes.<br>
- Other indexes are being considered</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">&nbsp;</sp=
an></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB"><br></span=
></p><p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"f=
ont-size: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Impor=
tant
dates:</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">----------=
------</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Submission
(full paper) <span style=3D"">&nbsp;&nbsp;&nbsp;&nbsp; </span>March 1, 2011=
</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Notificati=
on
<span style=3D"">&nbsp;&nbsp;&nbsp;&nbsp; </span><span style=3D"">&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>April
10, 2011</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Registrati=
on
<span style=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; </span><span style=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>April 25, =
2011</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Camera
ready <span style=3D"">&nbsp;&nbsp;&nbsp;&nbsp; </span><span style=3D"">&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>Apri=
l 28, 2011</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">&nbsp;</sp=
an></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">&nbsp;</sp=
an></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Only
.pdf or .doc files will be accepted for paper submission. All received pape=
rs
will be acknowledged via an automated system.</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">&nbsp;</sp=
an></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Final
author manuscripts will be 8.5" x 11", not exceeding 6 pages; max 4
extra pages allowed at additional cost. The formatting instructions can be
found on the Instructions page. Helpful information for paper formatting ca=
n be
found on the here.</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">&nbsp;</sp=
an></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Your
paper should also comply with the additional editorial rules.</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">&nbsp;</sp=
an></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Once
you receive the notification of paper acceptance, you will be provided by t=
he
publisher an online author kit with all the steps an author needs to follow=
 to
submit the final version. The author kits URL will be included in the lette=
r of
acceptance.</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">&nbsp;</sp=
an></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">&nbsp;</sp=
an></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Poster
Forum:</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">----------=
---</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Posters
are welcome. Please submit the contributions following the instructions for=
 the
regular submissions using the "Submit a Paper" button and selecting
the contribution type as poster.<span style=3D"">&nbsp;
</span>Submissions are expected to be 6-8 slide deck. Posters will not be
published in the Proceedings. One poster with all the slides together shoul=
d be
used for discussions. Presenters will be allocated a space where they can
display the slides and discuss in an informal manner. The poster slide deck=
s
will be posted on the IARIA site.</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">&nbsp;</sp=
an></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">For
more details, see the Poster Forum explanation page.</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">&nbsp;</sp=
an></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Work
in Progress:</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">----------=
------</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Work-in-pr=
ogress
contributions are welcome. Please submit the contributions following the
instructions for the regular submissions using the "Submit a Paper"
button and selecting the contribution type as work in progress.<span style=
=3D"">&nbsp; </span>Authors should submit a four-page (maximum)
text manuscript in IEEE double-column format including the authors' names,
affiliations, email contacts. Contributors must follow the conference deadl=
ines,
describing early research and novel skeleton ideas in the areas of the
conference topics. The work will be published in the conference proceedings=
.</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">&nbsp;</sp=
an></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">For
more details, see the Work in Progress explanation page</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">&nbsp;</sp=
an></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">&nbsp;</sp=
an></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Technical
marketing/business/positioning presentations:</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">----------=
---------------------------------------------</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">The
conference initiates a series of business, technical marketing, and positio=
ning
presentations on the same topics. Speakers must submit a 10-12 slide deck
presentations with substantial notes accompanying the slides, in the .ppt
format (.pdf-ed). The slide deck will not be published in the conference=E2=
=80=99s CD
Proceedings. Presentations' slide decks will be posted on the IARIA's site.
Please send your presentations to [email-masked].</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">&nbsp;</sp=
an></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">&nbsp;</sp=
an></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Tutorials:=
</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">----------=
</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Tutorials
provide overviews of current high interest topics. Proposals should be for
three hour tutorials. Proposals must contain the title, the summary of the
content, and the biography of the presenter(s). The tutorials' slide decks =
will
be posted on the IARIA's site. Please send your proposals to [email-masked]=
g</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">&nbsp;</sp=
an></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">&nbsp;</sp=
an></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Panel
proposals:</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">----------=
------</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">The
organizers encourage scientists and industry leaders to organize dedicated
panels dealing with controversial and challenging topics and paradigms. Pan=
el
moderators are asked to identify their guests and manage that their appropr=
iate
talk supports timely reach our deadlines. Moderators must specifically subm=
it
an official proposal, indicating their background, panelist names, their
affiliation, the topic of the panel, as well as short biographies. The pane=
l's
slide deck will be posted on the IARIA's site.</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">&nbsp;</sp=
an></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">For
more information, [email-masked]</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">&nbsp;</sp=
an></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">&nbsp;</sp=
an></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Workshop
proposals:</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">----------=
---------</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">We
welcome workshop proposals on issues complementary to the topics of this
conference. Your requests should be forwarded to [email-masked].</span></p=
>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB"><span styl=
e=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></p>

<p style=3D"margin: 0cm 0cm 0.0001pt;"><span style=3D"font-size: 10pt; font=
-family: &quot;Courier New&quot;;" lang=3D"EN-GB">GENERAL CHAIR</span></p>

<p style=3D"margin: 0cm 0cm 0.0001pt;"><span style=3D"font-size: 10pt; font=
-family: &quot;Courier New&quot;;" lang=3D"EN-GB">Josef Noll,
University of Oslo &amp; Movation, Norway </span></p>

<p style=3D"margin: 0cm 0cm 0.0001pt;"><strong><span style=3D"font-size: 10=
pt; font-family: &quot;Courier New&quot;; font-weight: normal;" lang=3D"EN-=
GB">&nbsp;</span></strong></p>

<p style=3D"margin: 0cm 0cm 0.0001pt;"><strong><span style=3D"font-size: 10=
pt; font-family: &quot;Courier New&quot;; font-weight: normal;" lang=3D"EN-=
GB">TECHNICAL PROGRAM COMMITTEE </span></strong><b style=3D""><span style=
=3D"font-size: 10pt; font-family: &quot;Courier New&quot;;" lang=3D"EN-GB">=
</span></b></p>

<p style=3D"margin: 0cm 0cm 0.0001pt;"><span style=3D"font-size: 10pt; font=
-family: &quot;Courier New&quot;;">Ramon Aguero Calvo, University of Cantab=
ria, Italy <br>
Nazim&nbsp;Agoulmine, University of Evry, France<br>
Ioannis Anagnostopoulos, University of Central Greece - Lamia, Greece <br>
Faouzi Bader, Centre Tecnologic de Telecomunicacions de Catalunya (CTTC), S=
pain
<br>
Payam M. Barnaghi, University of Surrey, United Kingdom<br>
Sonia Buchegger, KTH - Stockholm, Sweden <br>
Filipe Cabral Pinto, Telecom Inova=C3=A7=C3=A3o S.A., Portugal <br>
Jian-Nong Cao, Hong Kong Polytechnic University, Hong Kong <br>
Aline Carneiro Viana, INRIA Saclay - Ile de France - Orsay, France <br>
Mohammad Mushfiqur Chowdhury, University of Oslo, Norway <br>
Luis M. Correia, IST - Technical University of Lisbon, Portugal<br>
Klaus David, University of Kassel, Germany<br>
Kevin Deng, Jilin University, China<br>
Marco Fiore, INSA Lyon, INRIA, France <br>
</span><span style=3D"font-size: 10pt; font-family: &quot;Courier New&quot;=
;" lang=3D"IT"><span>Gianluca Franchino, CEIICP - Scuola
Superiore Sant'Anna - Pisa, Italy</span></span><span style=3D"font-size: 10=
pt; font-family: &quot;Courier New&quot;;"><br>
Joern Franke, SAP Research Center - Sophia Antipolis, France<br>
Rosario Garrido Cantos, University of Castilla-La-Mancha - Albacete, Spain =
<br>
Kamrul Hassan, Bangladesh University of Engineering and Technology, Banglad=
esh<br>
Peizhao Hu, NICTA, Australia<br>
Jiun-Long Huang, National Chiao Tung University, Taiwan<br>
Pekka J=C3=A4ppinen. Lappeenranta University of Technology, Finland<br>
Eduardo Juarez, Universidad Politecnica de Madrid (UPM), Spain <br>
Vana Kalogeraki, Athens University of Economics and Business, Greece<br>
Vasileios Karyotis, National Technical University of Athens (NTUA), Greece<=
br>
In-Young Ko,&nbsp; Korea Advanced Institute of Science and Technology (KAIS=
T),
Korea<br>
Brent Lagesse, Oak Ridge National Laboratory, USA<br>
</span><span style=3D"font-size: 10pt; font-family: &quot;Courier New&quot;=
;" lang=3D"SV"><span>Juhani Latvakoski, VTT, Finland</span></span><span sty=
le=3D"font-size: 10pt; font-family: &quot;Courier New&quot;;"><br>
Frank Yong Li, University Agder, Norway<br>
Seng Loke, La Trobe University, Australia<br>
Xun Luo, Qualcomm Inc. - San Diego, USA<br>
Satya Prasad Majumder, Bangladesh University of Engineering and Technology,
Bangladesh<br>
Behrouz Maham, UNIK-University Graduate Center, Norway<br>
Torleiv&nbsp;&nbsp;Maseng, FFI, Norway<br>
Constandinos Mavromoustakis, University of Nicosia, Cyprus<br>
Sandro Moiron, University of Essex, UK<br>
Luis Mu=C3=B1oz, University of Cantabria - Santander, Spain <br>
Masayuki Murata, Osaka University, Japan<br>
Norbert&nbsp;Niebert, Ericsson Eurolabs, Germany<br>
Josef Noll, University of Oslo &amp; Movation, Norway <br>
Jordi Ortiz Murillo, University of Murcia, Spain<br>
Knut =C3=98vsthus, Bergen University College, Norway<br>
Sangheon Pack, Korea University, Korea <br>
Paolo Pagano, Consorzio Nazionale Interuniversitario per le Telecomunicazio=
ni -
Pisa, Italy<br>
</span><span style=3D"font-size: 10pt; font-family: &quot;Courier New&quot;=
;" lang=3D"SV"><span>Marko Palviainen, VTT, Finland</span></span><span styl=
e=3D"font-size: 10pt; font-family: &quot;Courier New&quot;;"><br>
Riccardo Pascotto, T-Labs, Germany<br>
Prashant Pillai, University of Bradford, UK <br>
George C. Polyzos, Athens University of Economics and Business, Greece <br>
Stefan Poslad, Queen Mary University of London, UK<br>
Neeli R. Prasad, Aalborg University, Denmark<br>
Daniele Puccinelli, University of Applied Sciences of Southern Switzerland
(SUPSI), Switzerland<br>
Frank&nbsp;Reichert, University of Agder (UiA) - Grimstad, Norway<br>
Andreas Reinhardt, Technische Universit=C3=A4t Darmstadt (TU Darmstadt), Ge=
rmany<br>
Daniele Riboni, Universit=C3=A0 degli Studi di Milano, Italy<br>
Joel Rodr=C3=ACgues, University of Beira Interior - Covilh=C3=A3 / Institut=
o de
Telecomunica=C3=A7=C3=B5es, Portugal<br>
Chunming&nbsp;Rong, University of Stavanger, Norway<br>
Giancarlo Ruffo, University of Turin, Italy<br>
Sicari Sabrina, Universita degli studi dell'Insubria, Italy <br>
Farzad Salim, Queensland University of Technology, Australia <br>
Stefan Schmid, TU Berlin, Germany <br>
Behrooz Shirazi, Washington State University, USA<br>
Andrey Somov, CREATE-NET, Italy <br>
Xiang Song, Microsoft, USA<br>
<span>Stephan Steglich, FOKUS Fraunhofer, Germany</span><br>
Masashi Sugano, Osaka Prefecture University, Japan<br>
Mikko Uitto, VTT Technical Research Centre of Finland, Finland <br>
Amit Vasudevan, Carnegie Mellon University, USA <br>
Matthias Wagner, DOCOMO Euro-Labs, Germany<br>
Erik Wilde, University of California at Berkeley, USA<br>
Chansu Yu, Cleveland State University, USA<br>
Zhiwen Yu, Northwestern Polytechnical University, China<br>
Annie Zhao, GM Global R&amp;D Center, USA</span></p>

<p class=3D"MsoNormal" style=3D"text-align: justify;"><span style=3D"font-s=
ize: 10pt; font-family: &quot;Courier New&quot;;">&nbsp;</span></p><br></di=
v></body></html>
------=_Part_1373810_2012147162.1290451471895--

Content-class: urn:content-classes:message
Date: Thu, 18 Nov 2010 10:37:59 -0700
From: "Moore, Brad" <[email-masked]>
To: <[email-masked]>
Subject: [dtn-interest] comments on draft-irtf-dtnrg-ecos

I have some comments and questions regarding the ECOS extension block.

1) The block defines a "streaming" bit flag that when set indicates that
a bundle is to be
delivered "by invoking an adapter for a convergence layer protocol that
does NOT perform
retransmission of data lost in transit.  If the bundle protocol agent
has no access to 
such a convergence layer adapter then this flag may be ignored, but in
that case application 
data units may arrive out of transmission order at the destination
(possibly degrading 
application performance) and/or transmission bandwidth may be wasted on
unnecessary 
retranssion, reducing the effective throughput of the network."

I am questioning whether one bit provides enough control over the
reliability/bandwidth usage
of delivering a bundle.

I can envisage a CL that is capable of trying harder than other CL's to
successfully deliver a bundle to the next node, (eg. By increasing FEC
encoding, or higher levels of retries, or different ACKing schemes, etc)

The increased effort results in higher reliability, but at the expense
of higher bandwidth.

A variation of this idea would allow for such a CL to support multiple
levels of reliability, that can select an appropriate level of effort
based on a hint, or indication in the ECOS block.

While I am not sure how many effort "levels" would generally be useful,
I think allowing for three levels (High, Medium, Low) would probably
suffice, and would better meet the needs of a wider range of
applications.
Providing 3 or 4 reliability levels would require 2 bits instead of one
in the ECOS flags byte.
This is a possibility because currently only 3 of the 8 bits are
defined.

i.e., instead of 1 bit (streaming/low effort)

0 - retransmission OK - more effort
1 - streaming - No retransmission - least effort

We could have;

1 bit (streaming/low effort)
1 bit (reliable/high effort)

If only the streaming/low effort bit is set, this could indicate No
Retranmission.

If only the high effort bit is set, this could indicate high
reliability.

If both bits are set, then this indicates a compromise between levels of
effort (Medium effort)

If neither bit is set, then the level of effort is unspecified, and the
behavior could be the same
as if the ECOS block weren't present.

2) I think it would be useful to have another flag that indicates
discardability.

The idea is that if the bundle is marked as being discardable, and there
is queue build up at a Bundle Agent,
then the bundle may be discarded (deleted).

For example, this would be appropriate for certain data that is periodic
in nature, such as GPS location updates, where discarding an update is
OK, if we know another update will be coming along shortly.

The obsolesence block could also be used to do this, but I think that is
more appropriate for data that is not periodic in nature, eg. Status
data. Since you don't know whether a newer update will be coming along,
it's a better strategy to have newer status updates replace older status
updates.

The obsolesence block is higher cost though in terms of block
length/bandwidth usage, which is why having a discardability bit in the
ECOS flags byte would be useful.

I see discardability as being independent of bundle priority.
GPS location might be viewed as higher priority than normal messaging
traffic, however may be more discardable than the normal messaging
traffic.

It may even make sense to have two bits to indicate multiple levels of
discardability, 
(eg. dscp assured forwarding (RFC 2597) defines three levels for
drop-precedence which roughly corresponds to the discardability concept)

Should the ECOS block definition be extended to provide higher control
for the level of sending effort, and 
to provide a discardability indication?

Brad Moore

The information contained in this e-mail message is PRIVATE. It may contain confidential information and may be legally privileged. It is intended for the exclusive use of the addressee(s). If you are not the intended recipient, you are hereby notified that any dissemination, distribution or reproduction of this communication is strictly prohibited. If the intended recipient(s) cannot be reached or if a transmission problem has occurred, please notify the sender immediately by return e-mail and destroy all copies of this message. 
Thank you. 

Sender: Alex McMahon <[email-masked]>
From: Alex McMahon <[email-masked]>
To: Joerg Ott <[email-masked]>
Organization: Trinity College Dublin
Date: Thu, 18 Nov 2010 16:38:17 +0000
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] Moving I-Ds along or killing 'em...(author response required)
Reply-To: [email-masked]

On Tue, 2010-11-16 at 09:49 +0200, Joerg Ott wrote:
> > draft-irtf-dtnrg-dtn-uri-scheme, expired and currently dormant but can easily be revived if there's a renewal of interest
> 
> I think this will be needed as some other application-related
> stuff that went dormant for a while.  A must for non-closed
> deployments.

+1 for revival of draft-irtf-dtnrg-dtn-uri-scheme.

Alex 

Sender: Alex McMahon <[email-masked]>
From: Alex McMahon <[email-masked]>
To: Stephen Farrell <[email-masked]>
Organization: Trinity College Dublin
Date: Thu, 18 Nov 2010 16:37:20 +0000
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] Moving I-Ds along or killing 'em...(author response required)
Reply-To: [email-masked]

Plan to reissue expired draft-mcmahon-dtnrg-dtn-edp in about a month (at
same state 7) with some updates pending outcome of research. Have time
dedicated to moving the document forward and for writing some code.
Intend a state change 7->6 in about three months if there is interest.
Draft has dependencies on progression of draft-fall-dtnrg-schl (state
change 7->6) and revival of draft-irtf-dtnrg-dtn-uri-scheme. 

Alex

On Mon, 2010-11-15 at 20:32 +0000, Stephen Farrell wrote:
> Hi all,
> 
> All (or almost all) those DTN related I-Ds are presumably
> intended to become RFCs. There's a big bunch so I want to
> put some manners on the set, in terms of when we plan to
> get done with each.
> 
> I've sorted the on-line list into various states, some of
> which I've just invented but all of which should be obvious
> for anyone familiar with IETF or IRTF processes. The
> full list is below.
> 
> Can document authors please reply to this mail with your
> plans for state changes for your documents? If I hear nothing,
> I'm gonna treat 'em as OBE or "probably dead."
> 
> In each case, please clearly say which I-D, (just give
> the name), which state change (e.g. "7->6") you think
> is next, when you think that could happen (e.g. "in
> about two months") with realism being appreciated, and
> if the new state is not OBE or dead, (i.e. 8, 9 or
> 10), then please also give an assurance that you have
> the time available for moving the document forward.
> 
> Negative information is also welcome, e.g. saying
> "would like draft-foo to go from 6->5, think that'd
> take a month or so but I don't have time, so
> suggest transitioning from 6->8"
> 
> And since its a long list, if you spot a plain error,
> just reply with a suggested fix.
> 
> I'd like all responses that imply future work for
> me in the near future by the end of next week please.
> That basically means anything about which I hear
> nothing before November 28 will be treated by me
> as being in one of states 8,9 or 10.
> 
> Once I get all that, I'll try see if there's a
> sensible bunch to send to the IRSG at once, of if
> we just do 'em one at a time.
> 
> Thanks,
> Stephen.
> DTNRG-related I-D status, 2010-11-15
> [email-masked]
> Format is <last-rev-date,I-D-name>
> 
> 1. RFC already
> 
> 25-Jun-2008,draft-irtf-dtnrg-ltp-extensions
> 25-Jun-2008,draft-irtf-dtnrg-ltp-motivation
> 25-Jun-2008,draft-irtf-dtnrg-ltp
> 05-Jul-2007,draft-irtf-dtnrg-bundle-spec
> 15-Dec-2006,draft-irtf-dtnrg-arch
> 
> 2. RFC editor queue
> 
> Nothing
> 
> 3. IESG "end-run" review
> (Actually, I've not yet asked, gotta assemble the
> electronic paperwork in the next few days.)
> 
> 11-Nov-2010,draft-irtf-dtnrg-cbhe
> 25-Oct-2010,draft-irtf-dtnrg-prophet
> 25-Oct-2010,draft-irtf-dtnrg-iana-bp-registries
> 11-Oct-2010,draft-irtf-dtnrg-sdnv
> 13-Sep-2010,draft-irtf-dtnrg-bundle-security
> 08-Jul-2010,draft-irtf-dtnrg-bundle-metadata-block
> 
> 4. IRSG review
> 
> Nothing
> 
> 5. DTNRG "last-call-like-state"
> 
> Nothing
> 
> 6. work-in-progress, "accepted" by RG
> 
> 14-Nov-2010,draft-irtf-dtnrg-bundle-checksum
> 11-Nov-2010,draft-irtf-dtnrg-ecos
> 25-Oct-2010,draft-irtf-dtnrg-bundle-age-block
> 17-May-2010,draft-irtf-dtnrg-bundle-previous-hop-block
> 08-Mar-2010,draft-irtf-dtnrg-ipnd
> 09-Feb-2010,draft-irtf-dtnrg-ding-network-management
> 05-Oct-2009,draft-irtf-dtnrg-bundle-retrans-block
> 12-Aug-2009,draft-irtf-dtnrg-bundle-divert
> 12-Aug-2009,draft-irtf-dtnrg-bundle-encapsulation
> 31-Mar-2009,draft-irtf-dtnrg-dtn-uri-scheme
> 09-Mar-2009,draft-irtf-dtnrg-sec-overview
> 09-Mar-2009,draft-irtf-dtnrg-bundle-eidrefs
> 09-Mar-2009,draft-irtf-dtnrg-bundle-metadata-conf
> 19-Nov-2008,draft-irtf-dtnrg-udp-clayer
> 03-Nov-2008,draft-irtf-dtnrg-tcp-clayer
> 
> 7. work-in-progress (individual)
> 
> 14-Nov-2010,draft-wood-dtnrg-saratoga
> 14-Nov-2010,draft-wood-dtnrg-http-dtn-delivery
> 08-Nov-2010,draft-uehara-dtnrg-decentralized-probe-message
> 08-Nov-2010,draft-uehara-dtnrg-decentralized-probe-transport
> 08-Nov-2010,draft-farrell-dtnrg-bpq
> 20-Aug-2010,draft-burleigh-dtnrg-ltpcl
> 09-Jul-2010,draft-burleigh-dtnrg-cgr
> 28-Feb-2010,draft-fall-dtnrg-schl
> 27-Feb-2010,draft-mcmahon-dtnrg-dtn-edp
> 26-Oct-2009,draft-davies-dtnrg-uri-find
> 
> 8. Overtaken by events (OBE)
> 
> Nothing
> 
> 9. Probably dead (maybe worth reviving?)
> 
> 22-May-2009,draft-pbasu-dtnrg-naming
> 19-Jun-2007,draft-farrell-dtnrg-km
> 17-Apr-2007,draft-kutscher-dtnrg-uni-clayer
> 18-Nov-2007,draft-wyllie-dtnrg-badisc
> 13-Nov-2007,draft-ott-dtnrg-dtn-appl
> 26-May-2006,draft-eddy-dtnrg-eid
> 
> 10. Almost certainly dead (just checking)
> 
> 22-Mar-2010,draft-blanchet-dtnrg-iana-registries
> 24-Feb-2010,draft-ellard-dtnrg-reltime-htl
> 23-Nov-2009,draft-farrell-dtnrg-alt-time
> 12-Aug-2009,draft-symington-dtnrg-bundle-multicast-custodial
> 06-Jun-2009,draft-ivancic-dtnrg-network-management-reqs
> 08-Feb-2008,draft-symington-dtnrg-bundle-metadata-block
> 14-Aug-2007,draft-eddy-dtnrg-checksum
> 29-May-2007,draft-lindgren-dtnrg-prophet
> 18-Oct-2006,draft-demmer-dtnrg-tcp-clayer
> 13-Oct-2006,draft-symington-dtnrg-bundle-retrans-block
> 27-Oct-2003,draft-irtf-dtnrg-ipn-bundle-xfer
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: "Ray, Robert E. (MSFC-EV43)[JACOBS ENGINEERING GROUP INC]" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Thu, 18 Nov 2010 10:03:26 -0600
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] time representation

>How about we encode the seconds and fractional seconds as
>two fields with the latter as an SDNV - if you don't want
>subsecond precision then the value would be 0x00 consuming
>about a much as a flag would, and the fractional seconds
>precision determined by the length of that field? So, a
>fractional value of 123 means 123 ms, a factional value of
>456789 means us etc. (Or something equivalent - can't
>recall if SDNV decoding is supposed to strip leading
>zeros or not.)
>
>S.

Splitting the time values into two fields has implications for SNMP/network management information base, specifically with the LTP MIB schedule tables.  

I would suggest using a 48-bit SDNV with millisecond resolution, which represents the number of milliseconds since 20000101000000Z.  This fits within an 8 byte OCTET STRING and is usable as an SNMP index.  

A limitation with the SNMP is that 64-bit integers must not be used as table indices, but OCTET STRINGs may.

In case no one replied, SDNV encoding is akin to ASN.1 BER (basic encoding rules), where leading zeros are not encoded/transmitted.

Regards,
Bob Ray

Advanced Avionics and Processor Systems
Jacobs/ESTS
Marshall Space Flight Center
EV43, Bldg. 4487, Rm B183
(256) 544-0604 (W)

Sender: Alex McMahon <[email-masked]>
From: Alex McMahon <[email-masked]>
To: Joerg Ott <[email-masked]>
Organization: Trinity College Dublin
Date: Thu, 18 Nov 2010 15:48:01 +0000
Cc: [email-masked]
Subject: Re: [dtn-interest] Change to TCP CL
Reply-To: [email-masked]

+1 to modification of the TCP CL to include the bundle length in the TCP
CL header. I believe it would be best included (once per bundle) in the
TCP CL header rather than specifying another type of extension block.
Amongst other benefits an initial hint of the bundle size would enable a
receiver of an incoming large bundle to send acks enabling the sender to
perform reactive fragmentation or a receiver to refuse reception of an
incoming bundle if its size is unacceptable (perhaps by replying with a
negative ack).  

If there is a consensus on doing this perhaps we could package it in the
release of DTN2 2.8

Alex
On Wed, 2010-11-17 at 16:55 +0200, Joerg Ott wrote:
> Looks like we could be in violent agreement :-)
> Let's see if there are other opinions.
> 
> Joerg
> 
> On 17.11.2010 15:36, Simon Perreault wrote:
> > On 2010-11-17 02:14, Joerg Ott wrote:
> >>> This would impose a new constraint on BP itself. Since the total size is
> >>> not in the primary block, it's possible to stream multiple blocks
> >>> without knowing in advance how large the bundle will be. This is very
> >>> similar to HTTP chunked transfer encoding.
> >>
> >> RFC 5050 only allows for a single payload block per bundle.
> >
> > I'm not talking about multiple payload blocks here. I'm talking about
> > multiple blocks, period.
> >
> >>> So what I'm saying is that adding this field is not without cost. It
> >>> would need to be well justified.
> >>
> >> I am all for carefully considering all the issues.  And it is very
> >> good to have this discussion.  I am not dependent nor keen on a specific
> >> solution; I am just bringing up what we encountered.
> >
> > We're on the same wavelength.
> >
> > And now I understand better where you're coming from. I think I can
> > upgrade my position from "mostly unfavourable" to "don't care". ;)
> >
> > Simon
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: Darren Long <[email-masked]>
Date: Thu, 18 Nov 2010 12:57:36 +0000
To: DTN Interest <[email-masked]>
Subject: Re: [dtn-interest] Anomaly sending to Interest list

Well I got both of those back so maybe the anomaly was a one off.  Sorry for the bother.

Darren

On 18 Nov 2010, at 12:51, Darren Long wrote:

> Hi,
> 
> In the thread on Changes to TCP-CL, I sent a response to Joerg's initial post that should probably have gone to the list reflector via:
> 	Delay Tolerant Networking Interest List <[email-masked]>
> as that address was in the CC list.  This post does appear in the list archive. but didn't appear to come out of the reflector.  I checked my preferences for the list and they are set to deliver copies of my posts to my subscribed email account.
> 
> When I resent the post with a manually modified CC address set to the following:
> 	DTN Interest <[email-masked]>
> my post did get copied back to me by the reflector.
> 
> Both posts are now in the archive.  Is this expected behaviour? Have I missed something?
> 
> Cheers,
> 
> Darren
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: Darren Long <[email-masked]>
Date: Thu, 18 Nov 2010 12:51:47 +0000
To: DTN Interest <[email-masked]>, Delay Tolerant Networking Interest List <[email-masked]>
Subject: [dtn-interest] Anomaly sending to Interest list

Hi,

In the thread on Changes to TCP-CL, I sent a response to Joerg's initial post that should probably have gone to the list reflector via:
	Delay Tolerant Networking Interest List <[email-masked]>
as that address was in the CC list.  This post does appear in the list archive. but didn't appear to come out of the reflector.  I checked my preferences for the list and they are set to deliver copies of my posts to my subscribed email account.

When I resent the post with a manually modified CC address set to the following:
	DTN Interest <[email-masked]>
my post did get copied back to me by the reflector.

Both posts are now in the archive.  Is this expected behaviour? Have I missed something?

Cheers,

Darren

From: Darren Long <[email-masked]>
Date: Thu, 18 Nov 2010 12:51:47 +0000
To: DTN Interest <[email-masked]>, Delay Tolerant Networking Interest List <[email-masked]>
Subject: [dtn-interest] Anomaly sending to Interest list

Hi,

In the thread on Changes to TCP-CL, I sent a response to Joerg's initial post that should probably have gone to the list reflector via:
	Delay Tolerant Networking Interest List <[email-masked]>
as that address was in the CC list.  This post does appear in the list archive. but didn't appear to come out of the reflector.  I checked my preferences for the list and they are set to deliver copies of my posts to my subscribed email account.

When I resent the post with a manually modified CC address set to the following:
	DTN Interest <[email-masked]>
my post did get copied back to me by the reflector.

Both posts are now in the archive.  Is this expected behaviour? Have I missed something?

Cheers,

Darren

From: Darren Long <[email-masked]>
Date: Thu, 18 Nov 2010 12:38:51 +0000
To: Joerg Ott <[email-masked]>
Cc: DTN Interest <[email-masked]>
Subject: Re: [dtn-interest] Change to TCP CL

On 18 Nov 2010, at 11:39, Joerg Ott wrote:

> 
> Just a quick question: if AX.25 Connected Mode provides a reliable
> in-order transfer (just in 256 octet chunks), is there really a need
> to place a TCP segment header into each frame?  One strong checksum
> after a sequence of I frames (e.g., similar to AAL5) could be
> sufficient.

Well, AX.25 CM itself behaves as you say, but the maximum payload size can be less than 256 octets, as configured.  Short reads can cause splices in the payload data flow.  Also, there is a protocol called KISS (similar to SLIP) that conveys AX.25 frames from a host to a KISS modem which has no (or not enough) error detection capability.  There are occasional anomalies which I've found it hard to diagnose the cause of, so I have preferred to perform integrity checks in the CL shim (segment length and CRC).

Your suggestion sounds viable. Now that I've modified my CL implementation to send aggregated acks over an ack_window number of segments, and/or at the end of a bundle transfer (this being the granularity of reactive fragmentation) your approach could be more efficient.

It would require a fair bit of change though to the code, and for now at least, I think I might stick with the current approach, as the overhead is bounded (at least if the bundle size isn't added to each segment). Plus looking for the cause of anomalies at the segment level in data I've just received is hopefully easier than trying to figure out what went wrong over wider scope, I hope.

> 
>> I have a questions about the proposed change.  Is the intention to put an additional SDNV for the bundle length at the start of the first TCP-CLP segment of the bundle (i.e. the one with the S-Flag set), such that the overhead occurs only once in the bundle transfer, or in each TCP-CLP data segment that carries a part of the bundle?
> 
> Yes.  You only would need to include this once.  Then comes a series of
> segments that would not need a repetition of the length indicator.
> 
> Plus you would then need to provide mechanisms for handling inconsistent
> size indicators.  So, it is more efficient and saver to just send this
> once per bundle.
> 
> And, after all, the intention is to offer an initial hint of the bundle
> size to the receive to allow it to take a decision on whether or not
> this size is acceptable.

Fine.

> 
>> For large bundles, the cumulative overhead of including an SDNV for the bundle size in each TCP-CL Protocol segment could be expensive and on a 1200bps link (or worse) might best be avoided.
>> 
>> This potential issue doesn't simply affect the AX25CM-CL (running BP/TCP-CLP/AX.25) , as running TCP-CL Protocol over TCP (i.e. BP/TCP-CLP/TCP/IP/AX.25 or any other link layer with small MTU) would suffer similarly, but even more so due to the additional overhead of the transport and network layer headers eating into the 256 octet I-Frame payload.
> 
> I assume there would not be an issue for your case; you just get
> one additional SDNV value per bundle as overhead.

That's fine by me.  Are you intending to modify the DTN2 TCP-CL implementation?  If so, I'll look out for the changes and hack them into my CL too.  I don't merely mean the TCP-CLP format change, but presumably the processing that is assisted by the change will benefit my CL implementation too, and I'm not actually sure what functionality that is yet :)

Are you hoping to do this for the 2.8.0 release?

Cheers,

Darren

Date: Thu, 18 Nov 2010 13:39:15 +0200
From: Joerg Ott <[email-masked]>
To: Darren Long <[email-masked]>
Cc: Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] Change to TCP CL

Hi,

> My interest in this comes from the fact that I've reused (with minimal modification) the TCP-CL Protocol (and a fork of its implementation) in my AX.25 Connected Mode CL implementation for DTN2.

good point to keep these aligned.

> AX.25 Connected Mode provides a reliable, in-order transfer using a sequence of data-frames. The maximum payload size for an AX.25 I-Frame is 255 octets. Running the TCP-CL Protocol directly over AX.25 Connected Mode is pretty efficient without any transport or network layer headers.  Currently the degree of overhead for a maximum size TCP-CL Protocol Segment is 3 octets (plus my CL's additional CRC32 appended) for a 256 octet I-Frame payload.

Just a quick question: if AX.25 Connected Mode provides a reliable
in-order transfer (just in 256 octet chunks), is there really a need
to place a TCP segment header into each frame?  One strong checksum
after a sequence of I frames (e.g., similar to AAL5) could be
sufficient.

> I have a questions about the proposed change.  Is the intention to put an additional SDNV for the bundle length at the start of the first TCP-CLP segment of the bundle (i.e. the one with the S-Flag set), such that the overhead occurs only once in the bundle transfer, or in each TCP-CLP data segment that carries a part of the bundle?

Yes.  You only would need to include this once.  Then comes a series of
segments that would not need a repetition of the length indicator.

Plus you would then need to provide mechanisms for handling inconsistent
size indicators.  So, it is more efficient and saver to just send this
once per bundle.

And, after all, the intention is to offer an initial hint of the bundle
size to the receive to allow it to take a decision on whether or not
this size is acceptable.

> For large bundles, the cumulative overhead of including an SDNV for the bundle size in each TCP-CL Protocol segment could be expensive and on a 1200bps link (or worse) might best be avoided.
>
> This potential issue doesn't simply affect the AX25CM-CL (running BP/TCP-CLP/AX.25) , as running TCP-CL Protocol over TCP (i.e. BP/TCP-CLP/TCP/IP/AX.25 or any other link layer with small MTU) would suffer similarly, but even more so due to the additional overhead of the transport and network layer headers eating into the 256 octet I-Frame payload.
mailman/listinfo/dtn-interest

I assume there would not be an issue for your case; you just get
one additional SDNV value per bundle as overhead.

Cheers,
Joerg

From: Darren Long <[email-masked]>
Date: Thu, 18 Nov 2010 10:28:37 +0000
To: Joerg Ott <[email-masked]>
Cc: DTN Interest <[email-masked]>
Subject: Re: [dtn-interest] Change to TCP CL

Hi,

(I've resent this as it didn't seem to get sent out by the list reflector, but it is in the archive already, so sorry for the dupe).

My interest in this comes from the fact that I've reused (with minimal modification) the TCP-CL Protocol (and a fork of its implementation) in my AX.25 Connected Mode CL implementation for DTN2.

AX.25 Connected Mode provides a reliable, in-order transfer using a sequence of data-frames. The maximum payload size for an AX.25 I-Frame is 255 octets. Running the TCP-CL Protocol directly over AX.25 Connected Mode is pretty efficient without any transport or network layer headers.  Currently the degree of overhead for a maximum size TCP-CL Protocol Segment is 3 octets (plus my CL's additional CRC32 appended) for a 256 octet I-Frame payload.

I have a questions about the proposed change.  Is the intention to put an additional SDNV for the bundle length at the start of the first TCP-CLP segment of the bundle (i.e. the one with the S-Flag set), such that the overhead occurs only once in the bundle transfer, or in each TCP-CLP data segment that carries a part of the bundle?

For large bundles, the cumulative overhead of including an SDNV for the bundle size in each TCP-CL Protocol segment could be expensive and on a 1200bps link (or worse) might best be avoided.

This potential issue doesn't simply affect the AX25CM-CL (running BP/TCP-CLP/AX.25) , as running TCP-CL Protocol over TCP (i.e. BP/TCP-CLP/TCP/IP/AX.25 or any other link layer with small MTU) would suffer similarly, but even more so due to the additional overhead of the transport and network layer headers eating into the 256 octet I-Frame payload.

Cheers,

Darren

From: Darren Long <[email-masked]>
Date: Wed, 17 Nov 2010 18:47:03 +0000
To: Joerg Ott <[email-masked]>
Cc: Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] Change to TCP CL

Hi,

My interest in this comes from the fact that I've reused (with minimal modification) the TCP-CL Protocol (and a fork of its implementation) in my AX.25 Connected Mode CL implementation for DTN2.

AX.25 Connected Mode provides a reliable, in-order transfer using a sequence of data-frames. The maximum payload size for an AX.25 I-Frame is 255 octets. Running the TCP-CL Protocol directly over AX.25 Connected Mode is pretty efficient without any transport or network layer headers.  Currently the degree of overhead for a maximum size TCP-CL Protocol Segment is 3 octets (plus my CL's additional CRC32 appended) for a 256 octet I-Frame payload.

I have a questions about the proposed change.  Is the intention to put an additional SDNV for the bundle length at the start of the first TCP-CLP segment of the bundle (i.e. the one with the S-Flag set), such that the overhead occurs only once in the bundle transfer, or in each TCP-CLP data segment that carries a part of the bundle?

For large bundles, the cumulative overhead of including an SDNV for the bundle size in each TCP-CL Protocol segment could be expensive and on a 1200bps link (or worse) might best be avoided.

This potential issue doesn't simply affect the AX25CM-CL (running BP/TCP-CLP/AX.25) , as running TCP-CL Protocol over TCP (i.e. BP/TCP-CLP/TCP/IP/AX.25 or any other link layer with small MTU) would suffer similarly, but even more so due to the additional overhead of the transport and network layer headers eating into the 256 octet I-Frame payload.

Cheers,

Darren

Date: Wed, 17 Nov 2010 19:01:51 +0100 (CET)
From: [email-masked]
To: [email-masked]
Importance: Normal
Subject: [dtn-interest] [IEEE AOC 2011 - WoWMoM Workshop]: Preliminary Call for Papers

--------------------------------------------------------------------------------
                               CALL FOR PAPERS
                        Fifth IEEE WoWMoM Workshop on
             Autonomic and Opportunistic Communications (AOC 2011)
                        June 20, 2011 - Lucca (Italy)
                        http://cnd.iit.cnr.it/aoc2011/

                           jointly supported by the

                             SOCIALNETS project
                  funded by the FET-IST Programme under the
           FET proactive initiative on Pervasive Adaptation (PerAda)
                         http://www.social-nets.eu

                                   and
                              SCAMPI project
                  funded by the FP7-ICT Programme under the
         Future Internet Research and Experimentation (FIRE) initiative
                         http://www.ict-scampi.eu/

                 Fast Track on Computer Communication Journal
                   http://www.elsevier.com/locate/comcom

             **** Submission Deadline --- January 31, 2011 ****
--------------------------------------------------------------------------------

The diffusion  of lightweight, powerful  portable devices, also enriched  with a
variety of sensing capabilities, is  enabling new ways for users to communicate,
and is  laying the  foundation for  the ubiquitous networking  idea to  become a
reality.  Risen from the ashes of  traditional MANETs, which failed to cope with
the variability  of a  network solely made  up from mobile  users, opportunistic
communications have recently  stood out and gained a  lot of research attention.
Opportunistic networking is the enabling strategy for communications in a mobile
network.  The  idea of  opportunistically exploiting extemporary  contacts among
the  users  of the  network  poses  new and  challenging  problems,  as well  as
providing  with novel and  promising opportunities,  to the  networking research
community.  The AOC 2011 workshop will  be a meeting point for people working in
the area  and it will constitute  a forum to exchange  ideas, discuss solutions,
and  share   experiences  among  researchers,   professionals,  and  application
developers, both from industry and academia.   The AOC 2011 workshop will have a
primary  interest   in  the  new  directions   of  opportunistic  communications
represented  by  mobile   social  networking,  content-centric  networking,  and
participatory  sensing.  More  in  general, papers  tackling  issues related  to
opportunistic networking and computing  are welcome.  Original papers addressing
both  theoretical   and  practical   aspects  of  autonomic   and  opportunistic
communications   are  solicited,   as  well   as  papers   describing  prototype
implementations and deployments.

Topics of interest include but are not limited to:

*  Architectures and models for autonomic and opportunistic communications
*  Advanced  technologies  for  enabling  autonomic  and  opportunistic
   communications
*  Tools and techniques for designing, analysing and building autonomic and
   opportunistic networks
*  Scaling laws and fundamental limits in autonomic and opportunistic
   communications
*  Performance modeling of autonomic and opportunistic communications
*  Autonomic and opportunistic communication testbeds and measurements
*  Algorithms, models, and architectures for opportunistic computing
*  Mechanisms, algorithms and testbeds for service provisioning in autonomic
   and opportunistic networks
*  Algorithms, models, and architectures for content centric autonomic and
   opportunistic networks
*  Mobile social networking in autonomic and opportunistic communications
*  Participatory and urban sensing in autonomic and opportunistic networks
*  Resource management techniques applied to autonomic and opportunistic
   communications
*  Context and social awareness in autonomic and opportunistic networks
*  Routing, transport, and reliability issues in autonomic and opportunistic
   communications
*  Techniques for data dissemination and replication in autonomic and
   opportunistic networks
*  Applications and middleware support for autonomic and opportunistic
   communications
*  Mobility models and statistical analysis of mobility traces
*  Trust, security, and reputation in autonomic and opportunistic
   communications
*  Socio-economic models for  autonomic and opportunistic communications

PAPER SUBMISSION AND PUBLICATION
--------------------------------

Papers should neither have been published elsewhere  nor being currently under
review  by another conference or journal. Guidelines  on paper submission  and
formatting are available at http://cnd.iit.cnr.it/aoc2011/.

Accepted papers will appear in the symposium proceedings published by IEEE. At
least  one author of  each accepted paper  is required to register and present
his/her work at the workshop.

Extended versions  of workshop selected papers will be considered for possible
fast  track publication  on  the  Computer Communications  Journal (Elsevier).

IMPORTANT DATES
---------------
Full papers due:   January 31, 2011
Notification:      March 28, 2011

ORGANIZING COMMITTEE
--------------------

WORKSHOP Chair
  Elena Pagani, Universita' degli Studi di Milano, Italy

WORKSHOP Vice-Chair
  Chiara Boldrini, IIT-CNR, Italy

STEERING Committee
  Marco Conti, IIT-CNR, Italy
  Silvia Giordano, SUPSI, Switzerland
  Ioannis Stavrakakis, University of Athens, Greece

PUBLICITY Chair
  Valerio Arnaboldi, IIT-CNR, Italy

PROGRAM COMMITTEE (tentative)
-----------------------------

Gergely Acs, BUTE, Hungary
Mostafa Ammar, Georgia Institute of Technology, USA
Giuseppe Bianchi, Universita degli Studi di Roma Tor Vergata, Italy
Eleonora Borgia, IIT-CNR, Italy
Andrew T. Campbell, Dartmouth College, USA
Vania Conan, Thales, France
Igor Curcio, Nokia, Finland
Serge Fdida, UPCM Paris VI, France
Sabrina Gaito, Universita' degli Studi di Milano, Italy
Laura Galluccio, University of Catania, Italy
Mario Gerla, UCLA, USA
Philip Ginzboorg, Nokia, Finland
Merkourios Karaliopoulos, University of Athens, Greece
Mohan Kumar, University of Texas at Arlington, USA
Frack Legendre, ETH Zurich, Switzerland
Kyunghan Lee, KAIST, Korea
Daniele Miorandi, Create-net, Italy
Refik Molva, Eurecom, France
Giovanni Neglia, INRIA, France
Konstantinos Oikonomou, Ionian University, Greece
Joerg Ott, HUT, Finland
Andrea Passarella, IIT-CNR, Italy
Konstantinos Psounis, University of Southern California, USA
Daniele Puccinelli, SUPSI, Switzerland
Fabrizio Sestini, EU Commission
Abdullatif Shikfa, Alcatel Lucent Bell Labs, France
Thrasyvoulos Spyropoulos, EURECOM, France
Roger Whitaker, Cardiff University, UK
Hongyi Wu, University of Louisiana at Lafayette, USA
Eiko Yoneki, University of Cambridge, UK
Franco Zambonelli, University of Modena-Reggio, Italy
Xiaolan Zhang, Fordham University, USA

==============================================

Valerio Arnaboldi - AOC2011 Publicity Chair

Institute for Informatics and Telematics (IIT)
Italian National Research Council (CNR)
Via G. Moruzzi, 1 - 56124 Pisa, Italy
phone: +39 050 315 2195
email: [email-masked]

From: "Burleigh, Scott C (313B)" <[email-masked]>
To: Stephen Farrell <[email-masked]>, Dan Brown <[email-masked]>
Date: Wed, 17 Nov 2010 09:46:24 -0800
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Age Block / DTN2 discussion

I agree with retaining the sub-seconds field and I'm fine with it being microseconds.  Inferring the precision of the subseconds field from the length of the SDNV seems unnecessarily ingenious and an opportunity for multiple faulty implementations.

Scott

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Wednesday, November 17, 2010 5:28 AM
To: Dan Brown
Cc: [email-masked]
Subject: Re: [dtn-interest] Age Block / DTN2 discussion

On 17/11/10 12:31, Dan Brown wrote:
> 
> Hi Calvin.  Quick comment inline.
> 
>> -----Original Message-----
>> * The current Age block spec [1] calls for microseconds (Sec. 4) as the
>>   Age field; does anyone actually use or forsee a use for such
>>   precision? The bundle Creation Timestamp Time and Lifetime (RFC5050,
>>   Sec 4.5.1) use seconds, and I've currently implemented the Age with
>>   seconds (saves a few extra bits over the wire and a calculation here
>>   and there :) Unless there's anyone against it, I'll make the minor
>>   change on the next draft.
> 
> While I'm not convinced microsecond precision is necessary, I believe sub-second precision is.  Among other reasons is rounding error, which affects accumulated age at each hop, unlike the bundle's absolute time values.  Suppose a bundle goes 5 hops, spending 500 ms at each hop.  Limited to 1 second precision, the implementation must decide whether to increment the age by 0 or 1 seconds.  So after 5 hops, either the age is 0 or 5 seconds, when the actual bundle age is 2.5 seconds.  That can pose a difficulty for some terrestrial applications that tend toward the real-time, such as those being researched at BBN.

I think Dan's argument is a good one. I've no preference
between ms, us or even ns though, nor with encoding the
field so as to allow optional precision in any sensible way.

How about we encode the seconds and fractional seconds as
two fields with the latter as an SDNV - if you don't want
subsecond precision then the value would be 0x00 consuming
about a much as a flag would, and the fractional seconds
precision determined by the length of that field? So, a
fractional value of 123 means 123 ms, a factional value of
456789 means us etc. (Or something equivalent - can't
recall if SDNV decoding is supposed to strip leading
zeros or not.)

S.
_______________________________________________
dtn-interest mailing list
[email-masked]
http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Wed, 17 Nov 2010 17:04:49 +0000
From: Stephen Farrell <[email-masked]>
To: Calvin Ardi <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Age Block / DTN2 discussion

Hi Calvin,

I suggest we try resolve any spec issues first and then take
DTN2 related stuff to the dtn-users list. Sound ok? (I'm not
sure we have the same set of folks on both lists, so better if
we do it that way.)

On 17/11/10 04:00, Calvin Ardi wrote:

> Age Block:
> 
> * The current Age block spec [1] calls for microseconds (Sec. 4) as the
>   Age field; does anyone actually use or forsee a use for such
>   precision? The bundle Creation Timestamp Time and Lifetime (RFC5050,
>   Sec 4.5.1) use seconds, and I've currently implemented the Age with
>   seconds (saves a few extra bits over the wire and a calculation here
>   and there :) Unless there's anyone against it, I'll make the minor
>   change on the next draft.

Addressed in another sub-thread I guess.

> * The mechanism for signaling of the use of the Age block is to set the
>   Creation Timestamp Time to 0 (which I believe was to maintain
>   compliance with 5050?). It would be more useful to fill in the
>   Creation Timestamp Time field with the system time in addition to the
>   Age block. If the receiving BPA finds that the difference between the
>   Creation Timestamp Time + Lifetime and the current time is greater
>   than some value X, it can safely assume that either the sender's clock
>   or its own clock is out of sync and use the Age block instead.

Not sure I agree there - a lot of clocks may end up with 1970-01-01 or
some equivalent manuf specific epoch so this could generate odd and
unexpected behaviour if >1 node gets in that state. I'd say using 0
would be safer.

> * Storage management: another issue discussed briefly in the draft is
>   what happens when a BPA without a synchronized clock loses power and
>   wakes up. One way is to expire all of the bundles in the persistent
>   store and then delete them (5050, Sec. 5.5). I think a best-effort
>   approach, if time is not of the essence, would work better here:
> 
>   If there are enough resources to go around, why not just process and
>   send the bundles out to their intended destination? This could
>   potentially clutter up the network, but combined with a Class of
>   Service bit or ext block, we could label them as low priority and
>   create a policy as to how to handle them (e.g., if battery is < X% and
>   persistant store < Y%, delete bundles with low priority).

Hmmm...maybe. Not sure. The COS concerned is something like "this
bundle may be expired ages ago (or not yet valid) - I can't tell
since I lost my clock but here you go and do as you please" - is
that it?

I think the other issues were all DTN2 things, but if any are spec
changes/additions then please say which I've gotten wrong.
(Indicentally, I think I agree with almost all your DTN2 suggested
code changes, but let's do that in a bit on the dtn-users list.)

Cheers,
S.

Date: Wed, 17 Nov 2010 16:55:49 +0200
From: Joerg Ott <[email-masked]>
To: Simon Perreault <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Change to TCP CL

Looks like we could be in violent agreement :-)
Let's see if there are other opinions.

Joerg

On 17.11.2010 15:36, Simon Perreault wrote:
> On 2010-11-17 02:14, Joerg Ott wrote:
>>> This would impose a new constraint on BP itself. Since the total size is
>>> not in the primary block, it's possible to stream multiple blocks
>>> without knowing in advance how large the bundle will be. This is very
>>> similar to HTTP chunked transfer encoding.
>>
>> RFC 5050 only allows for a single payload block per bundle.
>
> I'm not talking about multiple payload blocks here. I'm talking about
> multiple blocks, period.
>
>>> So what I'm saying is that adding this field is not without cost. It
>>> would need to be well justified.
>>
>> I am all for carefully considering all the issues.  And it is very
>> good to have this discussion.  I am not dependent nor keen on a specific
>> solution; I am just bringing up what we encountered.
>
> We're on the same wavelength.
>
> And now I understand better where you're coming from. I think I can
> upgrade my position from "mostly unfavourable" to "don't care". ;)
>
> Simon

Date: Wed, 17 Nov 2010 08:36:38 -0500
From: Simon Perreault <[email-masked]>
To: Joerg Ott <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Change to TCP CL

On 2010-11-17 02:14, Joerg Ott wrote:
>> This would impose a new constraint on BP itself. Since the total size is
>> not in the primary block, it's possible to stream multiple blocks
>> without knowing in advance how large the bundle will be. This is very
>> similar to HTTP chunked transfer encoding.
> 
> RFC 5050 only allows for a single payload block per bundle.

I'm not talking about multiple payload blocks here. I'm talking about
multiple blocks, period.

>> So what I'm saying is that adding this field is not without cost. It
>> would need to be well justified.
> 
> I am all for carefully considering all the issues.  And it is very
> good to have this discussion.  I am not dependent nor keen on a specific
> solution; I am just bringing up what we encountered.

We're on the same wavelength.

And now I understand better where you're coming from. I think I can
upgrade my position from "mostly unfavourable" to "don't care". ;)

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

Date: Wed, 17 Nov 2010 13:27:33 +0000
From: Stephen Farrell <[email-masked]>
To: Dan Brown <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Age Block / DTN2 discussion

On 17/11/10 12:31, Dan Brown wrote:
> 
> Hi Calvin.  Quick comment inline.
> 
>> -----Original Message-----
>> * The current Age block spec [1] calls for microseconds (Sec. 4) as the
>>   Age field; does anyone actually use or forsee a use for such
>>   precision? The bundle Creation Timestamp Time and Lifetime (RFC5050,
>>   Sec 4.5.1) use seconds, and I've currently implemented the Age with
>>   seconds (saves a few extra bits over the wire and a calculation here
>>   and there :) Unless there's anyone against it, I'll make the minor
>>   change on the next draft.
> 
> While I'm not convinced microsecond precision is necessary, I believe sub-second precision is.  Among other reasons is rounding error, which affects accumulated age at each hop, unlike the bundle's absolute time values.  Suppose a bundle goes 5 hops, spending 500 ms at each hop.  Limited to 1 second precision, the implementation must decide whether to increment the age by 0 or 1 seconds.  So after 5 hops, either the age is 0 or 5 seconds, when the actual bundle age is 2.5 seconds.  That can pose a difficulty for some terrestrial applications that tend toward the real-time, such as those being researched at BBN.

I think Dan's argument is a good one. I've no preference
between ms, us or even ns though, nor with encoding the
field so as to allow optional precision in any sensible way.

How about we encode the seconds and fractional seconds as
two fields with the latter as an SDNV - if you don't want
subsecond precision then the value would be 0x00 consuming
about a much as a flag would, and the fractional seconds
precision determined by the length of that field? So, a
fractional value of 123 means 123 ms, a factional value of
456789 means us etc. (Or something equivalent - can't
recall if SDNV decoding is supposed to strip leading
zeros or not.)

S.

Date: Wed, 17 Nov 2010 08:21:54 -0500
From: Simon Perreault <[email-masked]>
To: Joerg Ott <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Change to TCP CL

On 2010-11-17 02:03, Joerg Ott wrote:
>> I don't think so. From the point of view of the receiver there is no
>> difference. Whether all the blocks in a bundle were produced first and
>> then sent, or whether they were sent as they were produced, it makes no
>> difference to the bits that go on the wire. Streaming only affects the
>> sending application, enabling it to be more efficient.
> 
> I am confused here.  What do you refer to by "all the blocks"

Well, to quote RFC 5050 section 4:

   Each bundle shall be a concatenated sequence of at least two block
   structures.  The first block in the sequence must be a primary bundle
   block, and no bundle may have more than one primary bundle block.
   Additional bundle protocol blocks of other types may follow the
   primary block to support extensions to the bundle protocol [...]

By "all the blocks" I mean "all the blocks in a given bundle".

> and why
> shouldn't they be produced before transmission?

It's not a SHOULD, it's a MAY.

An DTN application may opt to transmit blocks as they are produced for
the same reasons that a web application using HTTP chunked transfer
encoding may opt to transmit transmit chunks as they are produced.

> I admit that having
> security blocks such as a signature created while sending the bundle
> may make sense, but here you could predict the length of the signature.

I'm certain one could invent another type of extension block for which
this feature would be useful.

> Since only one payload block is allowed per bundle, which other
> surprises would you expect here?

I have no idea. BP allows this possibility now for future extensions. By
putting the bundle length in the TCPcl header we remove this possibility
(at least over TCP). It's just something to think about.

Simon
-- 
DTN made easy, smart, and lean --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

From: Dan Brown <[email-masked]>
To: Calvin Ardi <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 17 Nov 2010 12:31:03 +0000
Accept-Language: en-US
Subject: Re: [dtn-interest] Age Block / DTN2 discussion

Hi Calvin.  Quick comment inline.

> -----Original Message-----
> * The current Age block spec [1] calls for microseconds (Sec. 4) as the
>   Age field; does anyone actually use or forsee a use for such
>   precision? The bundle Creation Timestamp Time and Lifetime (RFC5050,
>   Sec 4.5.1) use seconds, and I've currently implemented the Age with
>   seconds (saves a few extra bits over the wire and a calculation here
>   and there :) Unless there's anyone against it, I'll make the minor
>   change on the next draft.

While I'm not convinced microsecond precision is necessary, I believe sub-second precision is.  Among other reasons is rounding error, which affects accumulated age at each hop, unlike the bundle's absolute time values.  Suppose a bundle goes 5 hops, spending 500 ms at each hop.  Limited to 1 second precision, the implementation must decide whether to increment the age by 0 or 1 seconds.  So after 5 hops, either the age is 0 or 5 seconds, when the actual bundle age is 2.5 seconds.  That can pose a difficulty for some terrestrial applications that tend toward the real-time, such as those being researched at BBN.

Date: Wed, 17 Nov 2010 09:14:39 +0200
From: Joerg Ott <[email-masked]>
To: Simon Perreault <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Moving I-Ds along or killing 'em...(author	response required)

Thanks for the reminder.  We won't forget these :-)

Joerg

On 16.11.2010 15:24, Simon Perreault wrote:
> On 2010-11-16 03:43, Joerg Ott wrote:
>> The draft's ready if we don't change anything.  But I see a good reason
>> for a change.  Gimme 5 min to post.
>
> I posted a few questions, see here:
> http://maillists.intel-research.net/pipermail/dtn-interest/2010-September/004796.html
>
> I hope they will be addressed in the next revision.
>
> Simon

Date: Wed, 17 Nov 2010 09:14:21 +0200
From: Joerg Ott <[email-masked]>
To: Simon Perreault <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Change to TCP CL

>> Currently implementations (including ours) peek into the bundle header
>> to figure out how the bundle is going to be so that they know where
>> to store the bundle (RAM vs flash/disk) and whether to accept it at
>> all (or reject it because it would not fit).
>
> Can you describe how your "peek" algorithm works? The only way to know a
> bundle's size is to iterate on block headers until you find one that has
> the "last block" flag. So basically there's a chance (e.g. when there is
> a small extension block after a large payload block) that you will need
> to store much of the bundle in RAM before you can know its size.

You need to do something like this.  But on the sender side, how you
organize your data structures internally (payload on disk vs. headers
in RAM as in DTN2) is a different matter.  So, no I do not think that
you need to have all of the bundle in RAM at any given time.

On the receiver side, one reasonable bet is to receive till you find
the payload block as this is likely to the dominant one in size.
Admittedly, this is making (optimistic) assumptions about extension
blocks being comparably small, but it appears justified given the
present specs.  We can always fail safely (albeit not efficiently)
if these guesses were wrong.

>> This is workable but not particularly clean.
>
> What do you not consider clean? Is it the peeking at the layer below
> that is bothering you, or is it the fact that the primary block does not
> contain the full bundle size and that forces you to iterate?

I wanna be able to change the layer above without having to revisit
the layer below and vice versa.  I am not a big fan engineering
perceived minor optimizations into a system at an early stage.

>> Our suggestion is to modify the TCP CL to include the bundle length
>> in the TCP CL header.  This would be a non-backward-compatible change.
>> (Doing this as an option would defeat the very purpose.)
>
> This would impose a new constraint on BP itself. Since the total size is
> not in the primary block, it's possible to stream multiple blocks
> without knowing in advance how large the bundle will be. This is very
> similar to HTTP chunked transfer encoding.

RFC 5050 only allows for a single payload block per bundle.

> If we were to add that field to TCPcl, it would eliminate that feature.

Since this feature does not exist (unless you misuse extension blocks
-- in which case I would disagree even more) nothing appears lost.

> So what I'm saying is that adding this field is not without cost. It
> would need to be well justified.

I am all for carefully considering all the issues.  And it is very
good to have this discussion.  I am not dependent nor keen on a specific
solution; I am just bringing up what we encountered.

Cheers,
Joerg

Date: Wed, 17 Nov 2010 09:03:50 +0200
From: Joerg Ott <[email-masked]>
To: Simon Perreault <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Change to TCP CL

Hi Simon,

>> is streaming bundles incompatible with custody transfer?
>
> I don't think so. From the point of view of the receiver there is no
> difference. Whether all the blocks in a bundle were produced first and
> then sent, or whether they were sent as they were produced, it makes no
> difference to the bits that go on the wire. Streaming only affects the
> sending application, enabling it to be more efficient.

I am confused here.  What do you refer to by "all the blocks" and why
shouldn't they be produced before transmission?  I admit that having
security blocks such as a signature created while sending the bundle
may make sense, but here you could predict the length of the signature.

Since only one payload block is allowed per bundle, which other
surprises would you expect here?

Joerg

Date: Wed, 17 Nov 2010 00:55:35 -0500
From: Brenton Walker <[email-masked]>
To: Joerg Ott <[email-masked]>
Cc: Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] Change to TCP CL

Hi Joerg,
	I've had similar concerns.  In mobile wireless tests I've seen a big
bundle effectively DOS a lot of nodes, intentionaly or unintentionally.
 It would be good to have a way to reject an incoming bundle before it
has a chance to do that.  Do you just close the link when a too-large
bundle is sent, or is there a less disruptive way to reject it?

	When setting up the Bundle game at Mobicom that was also something I
worried about, though there weren't enough bundle wranglers to cause any
mischief.  A related issue I couldn't solve, was limiting the scoring
database node to only accept bundles from authorized bundle relays.  I
guess it seems like there are reasons you might want to preemptively
reject a link or a bundle, but right now I don't know of a good way to
do either.  Of course maybe there are and I have just missed it.

Thanks,
Brenton

Joerg Ott wrote:
> Folks,
> 
> we came across some implementation issues with the present version
> of the TCP CL; it's been around for a while but we finally talked
> about this last week in Beijing.
> 
> A TCP CL header includes a segment length of a bundle, but this does
> not include the total bundle (fragment) length to be expected.
> 
> Currently implementations (including ours) peek into the bundle header
> to figure out how the bundle is going to be so that they know where
> to store the bundle (RAM vs flash/disk) and whether to accept it at
> all (or reject it because it would not fit).
> 
> This is workable but not particularly clean.
> 
> Our suggestion is to modify the TCP CL to include the bundle length
> in the TCP CL header.  This would be a non-backward-compatible change.
> (Doing this as an option would defeat the very purpose.)
> 
> We believe that we haven't reached a point in deployment where such
> changes would not be possible anymore and consider it useful to do
> such changes rather than start with workaround right away.
> 
> Joerg
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

Date: Tue, 16 Nov 2010 20:00:24 -0800
From: Calvin Ardi <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Age Block / DTN2 discussion

Hi everyone,

I've been prototyping the Age block [1] for DTN2 and hope to push it out
alongside the DTN2.8.0 release (after some code review and initial tests
on my end). Implementing the extension block has allowed me to go
through some of the underlying code and I'd like to bring up a few
points for discussion / comments regarding the Age block and future
iterations of DTN2.

Unless otherwise noted, most of the following refers specifically to
DTN2 implementation, but some can refer to the protocol in general.

  ----

Age Block:

* The current Age block spec [1] calls for microseconds (Sec. 4) as the
  Age field; does anyone actually use or forsee a use for such
  precision? The bundle Creation Timestamp Time and Lifetime (RFC5050,
  Sec 4.5.1) use seconds, and I've currently implemented the Age with
  seconds (saves a few extra bits over the wire and a calculation here
  and there :) Unless there's anyone against it, I'll make the minor
  change on the next draft.

* The mechanism for signaling of the use of the Age block is to set the
  Creation Timestamp Time to 0 (which I believe was to maintain
  compliance with 5050?). It would be more useful to fill in the
  Creation Timestamp Time field with the system time in addition to the
  Age block. If the receiving BPA finds that the difference between the
  Creation Timestamp Time + Lifetime and the current time is greater
  than some value X, it can safely assume that either the sender's clock
  or its own clock is out of sync and use the Age block instead.

  This will require some modification to how bundles are processed. If
  I'm getting this right, when a bundle is received, the Creation
  Timestamp Time and Lifetime is checked and then expiry decisions are
  made immediately after. Since there's the potential for additional
  information / metadata to be placed in ext blocks, the daemon should
  process the ext blocks contained in a bundle in addition to the
  primary block before making decisions on what to do with the bundle
  (this could include forwarding, expiration, storage management, etc).

  There's the potential for these ext blocks becoming very large and
  perhaps unwieldy for processing (especially in low power/embedded
  systems and environments) but at this point, overhead seems minimal.

* Known limitations: many. It's assumed that while your clock may be
  unsynchronized, it's at least capable of keeping track of how much
  time has elapsed (otherwise all bets are off).

  With the way ext blocks are handled, the Age for a new bundle is
  calculated as the time it takes from when a bundle is initialized (or
  when the ext block is consumed) until the ext block generate()
  function is called.
  
  This leaves a few gaps in the Age (some of which has been discussed in
  the draft but included for emphasis). Propagation delay tops the list;
  for now it's not taken into account. For some applications or networks
  this might be trivial, but it poses an interesting challenge as to how
  to calculate this. The consensus (as of 2010 March) was to push this
  burden to the convergence layer, which would require extensive
  modification to each convergence layer and moving more information
  between the daemon and CLs.

  The other gap is the time after generate() is called and before it's
  sent to the convergence layer queue. Thus, the Age does not factor the
  time it takes to process additional extension blocks, nor the time it
  sits on a link queue. Slightly trivial, but could be important if we
  have a busy BPA with, for example, a slow connection and many bundles
  to process.

  ----

DTN2 implementation:

* Run-time configuration: The use of extension blocks provides an easy
  way to implement new features, but at the moment there isn't a way to
  configure which BlockProcessors should be initialized or run. Because
  there might be the possibility that not everyone wants an Age block on
  their bundles (hypothetical of course, who wouldn't want the Age
  block? :) I've added some configuration options in dtn.conf to
  enable/disable certain aspects.

* Modularity: What I'd like to see is a more modular system for
  developing and enabling extension blocks without requiring a
  re-compile of DTN2 each time an ext block is developed/updated. I'm
  not sure if the current system supports it or how much additional work
  it'd require, but something similar to Apache2's module system would
  be awesome for DTN2 (e.g., see a2enmod/a2dismod on a Debian/Ubuntu
  system).  

* Minimal code changes to the DTN2 core: Following from the previous
  point, I've tried to make only the necessary changes to the DTN2 core
  as some of the logic / processing wasn't able to be contained within
  the BlockProcessor class. 

  For example, if we want to zero out the Creation Timestamp Time in
  conjunction with adding the Age block, we have to do that in the
  BundleDaemon as opposed to making that change in the BlockProcessor.

  Additionally, some metadata (Timers and a few other things) need to be
  stored to support the Age block and that's done by adding a few more
  variables to the Bundle class; it'd be nice to eventually have the
  situation where all of it could be contained in the BlockProcessor
  itself instead of addition additional fields and cluttering up the
  DTN2 core.

  ----

DTN:

* Storage management: another issue discussed briefly in the draft is
  what happens when a BPA without a synchronized clock loses power and
  wakes up. One way is to expire all of the bundles in the persistent
  store and then delete them (5050, Sec. 5.5). I think a best-effort
  approach, if time is not of the essence, would work better here:

  If there are enough resources to go around, why not just process and
  send the bundles out to their intended destination? This could
  potentially clutter up the network, but combined with a Class of
  Service bit or ext block, we could label them as low priority and
  create a policy as to how to handle them (e.g., if battery is < X% and
  persistant store < Y%, delete bundles with low priority).

I don't have all the solutions or the manpower to implement all these
ideas, but I'm definitely open to collaborating with anyone to get these
ideas off the ground. Any comments welcome.

Cheers,
Calvin

[1] http://tools.ietf.org/html/draft-irtf-dtnrg-bundle-age-block-01

Date: Tue, 16 Nov 2010 10:44:52 -0500
From: Simon Perreault <[email-masked]>
To: Vint Cerf <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Change to TCP CL

On 2010-11-16 10:23, Vint Cerf wrote:
> is streaming bundles incompatible with custody transfer?

I don't think so. From the point of view of the receiver there is no
difference. Whether all the blocks in a bundle were produced first and
then sent, or whether they were sent as they were produced, it makes no
difference to the bits that go on the wire. Streaming only affects the
sending application, enabling it to be more efficient.

I'm not discussing the case of starting to forward a partially-received
bundle. That would go against the procedures described in RFC 5050.

Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org

Date: Tue, 16 Nov 2010 10:23:46 -0500
From: Vint Cerf <[email-masked]>
To: Simon Perreault <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Change to TCP CL

--000325556ffe8dfa7104952d24db
Content-Type: text/plain; charset=ISO-8859-1

Simon,

is streaming bundles incompatible with custody transfer?

v

On Tue, Nov 16, 2010 at 8:39 AM, Simon Perreault <
[email-masked]> wrote:

> On 2010-11-16 03:51, Joerg Ott wrote:
> > Currently implementations (including ours) peek into the bundle header
> > to figure out how the bundle is going to be so that they know where
> > to store the bundle (RAM vs flash/disk) and whether to accept it at
> > all (or reject it because it would not fit).
>
> Can you describe how your "peek" algorithm works? The only way to know a
> bundle's size is to iterate on block headers until you find one that has
> the "last block" flag. So basically there's a chance (e.g. when there is
> a small extension block after a large payload block) that you will need
> to store much of the bundle in RAM before you can know its size.
>
> > This is workable but not particularly clean.
>
> What do you not consider clean? Is it the peeking at the layer below
> that is bothering you, or is it the fact that the primary block does not
> contain the full bundle size and that forces you to iterate?
>
> > Our suggestion is to modify the TCP CL to include the bundle length
> > in the TCP CL header.  This would be a non-backward-compatible change.
> > (Doing this as an option would defeat the very purpose.)
>
> This would impose a new constraint on BP itself. Since the total size is
> not in the primary block, it's possible to stream multiple blocks
> without knowing in advance how large the bundle will be. This is very
> similar to HTTP chunked transfer encoding.
>
> If we were to add that field to TCPcl, it would eliminate that feature.
>
> So what I'm saying is that adding this field is not without cost. It
> would need to be well justified.
>
> Simon
> --
> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
> STUN/TURN server        --> http://numb.viagenie.ca
> vCard 4.0               --> http://www.vcarddav.org
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

--000325556ffe8dfa7104952d24db
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Simon,<div><br></div><div>is streaming bundles incompatible with custody tr=
ansfer?</div><div><br></div><div>v</div><div><br><br><div class=3D"gmail_qu=
ote">On Tue, Nov 16, 2010 at 8:39 AM, Simon Perreault <span dir=3D"ltr">&lt=
;<a href=3D"mailto:[email-masked]">[email-masked]=
</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;"><div class=3D"im">On 2010-11-16 03:51, Joer=
g Ott wrote:<br>
&gt; Currently implementations (including ours) peek into the bundle header=
<br>
&gt; to figure out how the bundle is going to be so that they know where<br=
>
&gt; to store the bundle (RAM vs flash/disk) and whether to accept it at<br=
>
&gt; all (or reject it because it would not fit).<br>
<br>
</div>Can you describe how your &quot;peek&quot; algorithm works? The only =
way to know a<br>
bundle&#39;s size is to iterate on block headers until you find one that ha=
s<br>
the &quot;last block&quot; flag. So basically there&#39;s a chance (e.g. wh=
en there is<br>
a small extension block after a large payload block) that you will need<br>
to store much of the bundle in RAM before you can know its size.<br>
<div class=3D"im"><br>
&gt; This is workable but not particularly clean.<br>
<br>
</div>What do you not consider clean? Is it the peeking at the layer below<=
br>
that is bothering you, or is it the fact that the primary block does not<br=
>
contain the full bundle size and that forces you to iterate?<br>
<div class=3D"im"><br>
&gt; Our suggestion is to modify the TCP CL to include the bundle length<br=
>
&gt; in the TCP CL header. =A0This would be a non-backward-compatible chang=
e.<br>
&gt; (Doing this as an option would defeat the very purpose.)<br>
<br>
</div>This would impose a new constraint on BP itself. Since the total size=
 is<br>
not in the primary block, it&#39;s possible to stream multiple blocks<br>
without knowing in advance how large the bundle will be. This is very<br>
similar to HTTP chunked transfer encoding.<br>
<br>
If we were to add that field to TCPcl, it would eliminate that feature.<br>
<br>
So what I&#39;m saying is that adding this field is not without cost. It<br=
>
would need to be well justified.<br>
<br>
Simon<br>
<font color=3D"#888888">--<br>
NAT64/DNS64 open-source --&gt; <a href=3D"http://ecdysis.viagenie.ca" targe=
t=3D"_blank">http://ecdysis.viagenie.ca</a><br>
STUN/TURN server =A0 =A0 =A0 =A0--&gt; <a href=3D"http://numb.viagenie.ca" =
target=3D"_blank">http://numb.viagenie.ca</a><br>
vCard 4.0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 --&gt; <a href=3D"http://www.vcarddav=
.org" target=3D"_blank">http://www.vcarddav.org</a><br>
</font><div><div></div><div class=3D"h5">__________________________________=
_____________<br>
dtn-interest mailing list<br>
<a href=3D"mailto:[email-masked]">dtn-interest@m=
aillists.intel-research.net</a><br>
<a href=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interes=
t" target=3D"_blank">http://maillists.intel-research.net/mailman/listinfo/d=
tn-interest</a><br>
</div></div></blockquote></div><br></div>

--000325556ffe8dfa7104952d24db--

Date: Tue, 16 Nov 2010 08:39:49 -0500
From: Simon Perreault <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Change to TCP CL

On 2010-11-16 03:51, Joerg Ott wrote:
> Currently implementations (including ours) peek into the bundle header
> to figure out how the bundle is going to be so that they know where
> to store the bundle (RAM vs flash/disk) and whether to accept it at
> all (or reject it because it would not fit).

Can you describe how your "peek" algorithm works? The only way to know a
bundle's size is to iterate on block headers until you find one that has
the "last block" flag. So basically there's a chance (e.g. when there is
a small extension block after a large payload block) that you will need
to store much of the bundle in RAM before you can know its size.

> This is workable but not particularly clean.

What do you not consider clean? Is it the peeking at the layer below
that is bothering you, or is it the fact that the primary block does not
contain the full bundle size and that forces you to iterate?

> Our suggestion is to modify the TCP CL to include the bundle length
> in the TCP CL header.  This would be a non-backward-compatible change.
> (Doing this as an option would defeat the very purpose.)

This would impose a new constraint on BP itself. Since the total size is
not in the primary block, it's possible to stream multiple blocks
without knowing in advance how large the bundle will be. This is very
similar to HTTP chunked transfer encoding.

If we were to add that field to TCPcl, it would eliminate that feature.

So what I'm saying is that adding this field is not without cost. It
would need to be well justified.

Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org

Date: Tue, 16 Nov 2010 08:24:11 -0500
From: Simon Perreault <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Moving I-Ds along or killing 'em...(author	response required)

On 2010-11-16 03:43, Joerg Ott wrote:
> The draft's ready if we don't change anything.  But I see a good reason
> for a change.  Gimme 5 min to post.

I posted a few questions, see here:
http://maillists.intel-research.net/pipermail/dtn-interest/2010-September/004796.html

I hope they will be addressed in the next revision.

Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org

Date: Tue, 16 Nov 2010 10:51:46 +0200
From: Joerg Ott <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Subject: [dtn-interest] Change to TCP CL

Folks,

we came across some implementation issues with the present version
of the TCP CL; it's been around for a while but we finally talked
about this last week in Beijing.

A TCP CL header includes a segment length of a bundle, but this does
not include the total bundle (fragment) length to be expected.

Currently implementations (including ours) peek into the bundle header
to figure out how the bundle is going to be so that they know where
to store the bundle (RAM vs flash/disk) and whether to accept it at
all (or reject it because it would not fit).

This is workable but not particularly clean.

Our suggestion is to modify the TCP CL to include the bundle length
in the TCP CL header.  This would be a non-backward-compatible change.
(Doing this as an option would defeat the very purpose.)

We believe that we haven't reached a point in deployment where such
changes would not be possible anymore and consider it useful to do
such changes rather than start with workaround right away.

Joerg

Date: Tue, 16 Nov 2010 10:43:55 +0200
From: Joerg Ott <[email-masked]>
To: Stephen Farrell <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] Moving I-Ds along or killing 'em...(author	response required)

The draft's ready if we don't change anything.  But I see a good reason
for a change.  Gimme 5 min to post.

Joerg

On 16.11.2010 10:29, Stephen Farrell wrote:
>
>
> On 16/11/10 07:47, Joerg Ott wrote:
>> We just had some thoughts in the meeting last week and will post shortly
>> on this topic.
>
> Great. In the meantime, what's the plan in terms of the state
> of the I-D, and roughly for when? (So's we can see if there's
> a bunch to process together again.)
>
> Ta,
> S.
>
>>
>> Joerg
>>
>> On 16.11.2010 00:55, Hans Kruse wrote:
>>> Certainly needed.  Can't remember, but I thought someone committed to
>>> a re-issue on the list recently?
>>>
>>> On Nov 15, 2010, at 15:32 PM, Stephen Farrell wrote:
>>>
>>>> 03-Nov-2008,draft-irtf-dtnrg-tcp-clayer
>>>
>>>
>>> Hans Kruse, Professor
>>> J. Warren McClure School of Information and Telecommunication Systems
>>> Adjunct Associate Professor of Electrical Engineering and Computer
>>> Science
>>> Chief Operating Officer, GRID Lab
>>> 292 Lindley Hall, Ohio University, Athens, OH, 45701
>>> 740-593-4891 voice, 740-593-4889 fax
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> dtn-interest mailing list
>>> [email-masked]
>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>>
>>
>

Date: Tue, 16 Nov 2010 08:29:06 +0000
From: Stephen Farrell <[email-masked]>
To: Joerg Ott <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] Moving I-Ds along or killing 'em...(author	response required)

On 16/11/10 07:47, Joerg Ott wrote:
> We just had some thoughts in the meeting last week and will post shortly
> on this topic.

Great. In the meantime, what's the plan in terms of the state
of the I-D, and roughly for when? (So's we can see if there's
a bunch to process together again.)

Ta,
S.

> 
> Joerg
> 
> On 16.11.2010 00:55, Hans Kruse wrote:
>> Certainly needed.  Can't remember, but I thought someone committed to
>> a re-issue on the list recently?
>>
>> On Nov 15, 2010, at 15:32 PM, Stephen Farrell wrote:
>>
>>> 03-Nov-2008,draft-irtf-dtnrg-tcp-clayer
>>
>>
>> Hans Kruse, Professor
>> J. Warren McClure School of Information and Telecommunication Systems
>> Adjunct Associate Professor of Electrical Engineering and Computer
>> Science
>> Chief Operating Officer, GRID Lab
>> 292 Lindley Hall, Ohio University, Athens, OH, 45701
>> 740-593-4891 voice, 740-593-4889 fax
>>
>>
>>
>>
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>
> 

Date: Tue, 16 Nov 2010 09:49:54 +0200
From: Joerg Ott <[email-masked]>
To: "Burleigh, Scott C (313B)" <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] Moving I-Ds along or killing 'em...(author response required)

> draft-irtf-dtnrg-dtn-uri-scheme, expired and currently dormant but can easily be revived if there's a renewal of interest

I think this will be needed as some other application-related
stuff that went dormant for a while.  A must for non-closed
deployments.

Joerg

Date: Tue, 16 Nov 2010 09:47:57 +0200
From: Joerg Ott <[email-masked]>
To: Hans Kruse <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] Moving I-Ds along or killing 'em...(author	response required)

We just had some thoughts in the meeting last week and will post shortly
on this topic.

Joerg

On 16.11.2010 00:55, Hans Kruse wrote:
> Certainly needed.  Can't remember, but I thought someone committed to a re-issue on the list recently?
>
> On Nov 15, 2010, at 15:32 PM, Stephen Farrell wrote:
>
>> 03-Nov-2008,draft-irtf-dtnrg-tcp-clayer
>
>
> Hans Kruse, Professor
> J. Warren McClure School of Information and Telecommunication Systems
> Adjunct Associate Professor of Electrical Engineering and Computer Science
> Chief Operating Officer, GRID Lab
> 292 Lindley Hall, Ohio University, Athens, OH, 45701
> 740-593-4891 voice, 740-593-4889 fax
>
>
>
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

From: Keiichi SHIMA <[email-masked]>
Date: Tue, 16 Nov 2010 12:45:02 +0900
To: Stephen Farrell <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] Moving I-Ds along or killing 'em...(author response required)

Hello,

08-Nov-2010,draft-uehara-dtnrg-decentralized-probe-message
08-Nov-2010,draft-uehara-dtnrg-decentralized-probe-transport

7->7 (or 6, depends on the progress).  We will revise these documents to fit the approaches and protocols defined in the DTNRG.  We plan to publish revised documents once or twice before next IETF.

---
Keiichi SHIMA
Research Laboratory, IIJ Innovation Institute  <[email-masked]>
WIDE Project <[email-masked]>

On Nov 16, 2010, at 5:43 AM, Stephen Farrell wrote:

> 
> My guesses for things for which I'm an author:
> 
> - draft-irtf-bundle-age-block, 6->5 once someone
> writes code, maybe 6 months or so, I'll help
> 
> - draft-irtf-dtnrg-sec-overview, 6->5 once the
> BSP is actually an RFC, maybe take two revs to
> be done, I'll work on i
> 
> - draft-farrell-dtnrg-bpq, 7-> 6, that can
> happen now I think if folks are ok with it, I'll
> work on it (we're starting to code it up now)
> 
> - draft-farrell-dtnrg-km, 9->8, I've tried a
> few times, but no-one seems to have cycles to
> do work on this
> 
> S.
> 
> PS: for documents with >1 author, its ok to get
>> 1 response (more is better:-)
> 
> On 15/11/10 20:32, Stephen Farrell wrote:
>> 
>> Hi all,
>> 
>> All (or almost all) those DTN related I-Ds are presumably
>> intended to become RFCs. There's a big bunch so I want to
>> put some manners on the set, in terms of when we plan to
>> get done with each.
>> 
>> I've sorted the on-line list into various states, some of
>> which I've just invented but all of which should be obvious
>> for anyone familiar with IETF or IRTF processes. The
>> full list is below.
>> 
>> Can document authors please reply to this mail with your
>> plans for state changes for your documents? If I hear nothing,
>> I'm gonna treat 'em as OBE or "probably dead."
>> 
>> In each case, please clearly say which I-D, (just give
>> the name), which state change (e.g. "7->6") you think
>> is next, when you think that could happen (e.g. "in
>> about two months") with realism being appreciated, and
>> if the new state is not OBE or dead, (i.e. 8, 9 or
>> 10), then please also give an assurance that you have
>> the time available for moving the document forward.
>> 
>> Negative information is also welcome, e.g. saying
>> "would like draft-foo to go from 6->5, think that'd
>> take a month or so but I don't have time, so
>> suggest transitioning from 6->8"
>> 
>> And since its a long list, if you spot a plain error,
>> just reply with a suggested fix.
>> 
>> I'd like all responses that imply future work for
>> me in the near future by the end of next week please.
>> That basically means anything about which I hear
>> nothing before November 28 will be treated by me
>> as being in one of states 8,9 or 10.
>> 
>> Once I get all that, I'll try see if there's a
>> sensible bunch to send to the IRSG at once, of if
>> we just do 'em one at a time.
>> 
>> Thanks,
>> Stephen.
>> DTNRG-related I-D status, 2010-11-15
>> [email-masked]
>> Format is <last-rev-date,I-D-name>
>> 
>> 1. RFC already
>> 
>> 25-Jun-2008,draft-irtf-dtnrg-ltp-extensions
>> 25-Jun-2008,draft-irtf-dtnrg-ltp-motivation
>> 25-Jun-2008,draft-irtf-dtnrg-ltp
>> 05-Jul-2007,draft-irtf-dtnrg-bundle-spec
>> 15-Dec-2006,draft-irtf-dtnrg-arch
>> 
>> 2. RFC editor queue
>> 
>> Nothing
>> 
>> 3. IESG "end-run" review
>> (Actually, I've not yet asked, gotta assemble the
>> electronic paperwork in the next few days.)
>> 
>> 11-Nov-2010,draft-irtf-dtnrg-cbhe
>> 25-Oct-2010,draft-irtf-dtnrg-prophet
>> 25-Oct-2010,draft-irtf-dtnrg-iana-bp-registries
>> 11-Oct-2010,draft-irtf-dtnrg-sdnv
>> 13-Sep-2010,draft-irtf-dtnrg-bundle-security
>> 08-Jul-2010,draft-irtf-dtnrg-bundle-metadata-block
>> 
>> 4. IRSG review
>> 
>> Nothing
>> 
>> 5. DTNRG "last-call-like-state"
>> 
>> Nothing
>> 
>> 6. work-in-progress, "accepted" by RG
>> 
>> 14-Nov-2010,draft-irtf-dtnrg-bundle-checksum
>> 11-Nov-2010,draft-irtf-dtnrg-ecos
>> 25-Oct-2010,draft-irtf-dtnrg-bundle-age-block
>> 17-May-2010,draft-irtf-dtnrg-bundle-previous-hop-block
>> 08-Mar-2010,draft-irtf-dtnrg-ipnd
>> 09-Feb-2010,draft-irtf-dtnrg-ding-network-management
>> 05-Oct-2009,draft-irtf-dtnrg-bundle-retrans-block
>> 12-Aug-2009,draft-irtf-dtnrg-bundle-divert
>> 12-Aug-2009,draft-irtf-dtnrg-bundle-encapsulation
>> 31-Mar-2009,draft-irtf-dtnrg-dtn-uri-scheme
>> 09-Mar-2009,draft-irtf-dtnrg-sec-overview
>> 09-Mar-2009,draft-irtf-dtnrg-bundle-eidrefs
>> 09-Mar-2009,draft-irtf-dtnrg-bundle-metadata-conf
>> 19-Nov-2008,draft-irtf-dtnrg-udp-clayer
>> 03-Nov-2008,draft-irtf-dtnrg-tcp-clayer
>> 
>> 7. work-in-progress (individual)
>> 
>> 14-Nov-2010,draft-wood-dtnrg-saratoga
>> 14-Nov-2010,draft-wood-dtnrg-http-dtn-delivery
>> 08-Nov-2010,draft-uehara-dtnrg-decentralized-probe-message
>> 08-Nov-2010,draft-uehara-dtnrg-decentralized-probe-transport
>> 08-Nov-2010,draft-farrell-dtnrg-bpq
>> 20-Aug-2010,draft-burleigh-dtnrg-ltpcl
>> 09-Jul-2010,draft-burleigh-dtnrg-cgr
>> 28-Feb-2010,draft-fall-dtnrg-schl
>> 27-Feb-2010,draft-mcmahon-dtnrg-dtn-edp
>> 26-Oct-2009,draft-davies-dtnrg-uri-find
>> 
>> 8. Overtaken by events (OBE)
>> 
>> Nothing
>> 
>> 9. Probably dead (maybe worth reviving?)
>> 
>> 22-May-2009,draft-pbasu-dtnrg-naming
>> 19-Jun-2007,draft-farrell-dtnrg-km
>> 17-Apr-2007,draft-kutscher-dtnrg-uni-clayer
>> 18-Nov-2007,draft-wyllie-dtnrg-badisc
>> 13-Nov-2007,draft-ott-dtnrg-dtn-appl
>> 26-May-2006,draft-eddy-dtnrg-eid
>> 
>> 10. Almost certainly dead (just checking)
>> 
>> 22-Mar-2010,draft-blanchet-dtnrg-iana-registries
>> 24-Feb-2010,draft-ellard-dtnrg-reltime-htl
>> 23-Nov-2009,draft-farrell-dtnrg-alt-time
>> 12-Aug-2009,draft-symington-dtnrg-bundle-multicast-custodial
>> 06-Jun-2009,draft-ivancic-dtnrg-network-management-reqs
>> 08-Feb-2008,draft-symington-dtnrg-bundle-metadata-block
>> 14-Aug-2007,draft-eddy-dtnrg-checksum
>> 29-May-2007,draft-lindgren-dtnrg-prophet
>> 18-Oct-2006,draft-demmer-dtnrg-tcp-clayer
>> 13-Oct-2006,draft-symington-dtnrg-bundle-retrans-block
>> 27-Oct-2003,draft-irtf-dtnrg-ipn-bundle-xfer
>> 
>> 
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Tue, 16 Nov 2010 00:01:43 +0000
From: Stephen Farrell <[email-masked]>
To: "Clark, Gilbert" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Moving I-Ds along or killing 'em...(author response required)

On 15/11/10 23:54, Clark, Gilbert wrote:
> 09-Feb-2010,draft-irtf-dtnrg-ding-network-management
> 
> I believe the status of this document reflects an error in naming on my part more than any WG acceptance.  Thus, draft-irtf-dtnrg-ding-network-management probably should be listed as being in state 7 at the moment.

I knew there was one like that. Thanks.

S.

> 
> An updated version of this document will be reappearing as an (properly named) individual draft within the next 3-4 weeks.  I'd like to push for a transition from 7 -> 6 to happen after another version (or two) of this draft, so say within the next few months.
> 
> Thanks,
> Gilbert Clark
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

From: "Clark, Gilbert" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Mon, 15 Nov 2010 18:54:25 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Moving I-Ds along or killing 'em...(author response required)

09-Feb-2010,draft-irtf-dtnrg-ding-network-management

I believe the status of this document reflects an error in naming on my part more than any WG acceptance.  Thus, draft-irtf-dtnrg-ding-network-management probably should be listed as being in state 7 at the moment.

An updated version of this document will be reappearing as an (properly named) individual draft within the next 3-4 weeks.  I'd like to push for a transition from 7 -> 6 to happen after another version (or two) of this draft, so say within the next few months.

Thanks,
Gilbert Clark

From: "Burleigh, Scott C (313B)" <[email-masked]>
To: Stephen Farrell <[email-masked]>, DTN <[email-masked]>
Date: Mon, 15 Nov 2010 15:43:23 -0800
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Moving I-Ds along or killing 'em...(author response	required)

draft-irtf-dtnrg-cbhe, 3->2 on conclusion of review

draft-irtf-dtnrg-ecos, 6->5 after everybody has had a chance to comment on the latest edition, maybe a month?

[Note: draft-irtf-dtnrg-bundle-age-block is the successor to draft-ellard-dtnrg-reltime-htl; Calvin Ardi knows most about its status]

draft-irtf-dtnrg-dtn-uri-scheme, expired and currently dormant but can easily be revived if there's a renewal of interest

draft-burleigh-dtnrg-ltpcl, active and now (I think) fairly stable, would like to see 7->6 in the next month

draft-burleigh-dtnrg-cgr, active but not ready to change state any time soon

Scott

From: Dan Brown <[email-masked]>
To: Daniel Ellard <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 15 Nov 2010 23:41:31 +0000
Accept-Language: en-US
Subject: Re: [dtn-interest] Moving I-Ds along or killing 'em...(author response required)

> > 24-Feb-2010,draft-ellard-dtnrg-reltime-htl
> 
> Dead.
> 
> I'm not sure which of these is the one that superseded it, and I want to
> make sure that someone is pushing forward on that.  (Dan Brown, who was
> working on it, has moved on to other pursuits, and I'm not sure whether he's
> even on this list any more)

I lurk.  ;)   This would be superseded by the age-block draft, which I believe Calvin Ardi has largely taken the lead on.  Was under the impression that implementation efforts for DTN-2 might be in the works.

From: Hans Kruse <[email-masked]>
Date: Mon, 15 Nov 2010 18:06:16 -0500
To: Stephen Farrell <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] Moving I-Ds along or killing 'em...(author response	required)

Should be on track for experimental RFC; new ID in 3-4 weeks, after that timing depends on the group ;).

On Nov 15, 2010, at 17:57 PM, Stephen Farrell wrote:

> 
> 
> On 15 Nov 2010, at 22:39, "Kruse, Hans" <[email-masked]> wrote:
> 
>> Will be reissued shortly,
> 
> ...and then what? (new state, timing?)
> 
> S
> 
>> we are completing some research that was needed to reply to comments.
>> 
>> On Nov 15, 2010, at 15:32 PM, Stephen Farrell wrote:
>> 
>>> 19-Nov-2008,draft-irtf-dtnrg-udp-clayer
>> 
>> Hans Kruse, Professor
>> J. Warren McClure School of Information and Telecommunication Systems
>> Adjunct Associate Professor of Electrical Engineering and Computer Science
>> Chief Operating Officer, GRID Lab
>> 292 Lindley Hall, Ohio University, Athens, OH, 45701
>> 740-593-4891 voice, 740-593-4889 fax
>> 
>> 
>> 
>> 

Hans Kruse, Professor
J. Warren McClure School of Information and Telecommunication Systems
Adjunct Associate Professor of Electrical Engineering and Computer Science
Chief Operating Officer, GRID Lab
292 Lindley Hall, Ohio University, Athens, OH, 45701
740-593-4891 voice, 740-593-4889 fax

From: Stephen Farrell <[email-masked]>
Date: Mon, 15 Nov 2010 22:57:17 +0000
To: "Kruse, Hans" <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] Moving I-Ds along or killing 'em...(author response	required)

On 15 Nov 2010, at 22:39, "Kruse, Hans" <[email-masked]> wrote:

> Will be reissued shortly,

...and then what? (new state, timing?)

S

> we are completing some research that was needed to reply to comments.
> 
> On Nov 15, 2010, at 15:32 PM, Stephen Farrell wrote:
> 
>> 19-Nov-2008,draft-irtf-dtnrg-udp-clayer
> 
> Hans Kruse, Professor
> J. Warren McClure School of Information and Telecommunication Systems
> Adjunct Associate Professor of Electrical Engineering and Computer Science
> Chief Operating Officer, GRID Lab
> 292 Lindley Hall, Ohio University, Athens, OH, 45701
> 740-593-4891 voice, 740-593-4889 fax
> 
> 
> 
> 

From: Hans Kruse <[email-masked]>
Date: Mon, 15 Nov 2010 17:55:01 -0500
To: Stephen Farrell <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] Moving I-Ds along or killing 'em...(author response	required)

Certainly needed.  Can't remember, but I thought someone committed to a re-issue on the list recently?

On Nov 15, 2010, at 15:32 PM, Stephen Farrell wrote:

> 03-Nov-2008,draft-irtf-dtnrg-tcp-clayer

Hans Kruse, Professor
J. Warren McClure School of Information and Telecommunication Systems
Adjunct Associate Professor of Electrical Engineering and Computer Science
Chief Operating Officer, GRID Lab
292 Lindley Hall, Ohio University, Athens, OH, 45701
740-593-4891 voice, 740-593-4889 fax

From: Hans Kruse <[email-masked]>
Date: Mon, 15 Nov 2010 17:54:10 -0500
To: Stephen Farrell <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] Moving I-Ds along or killing 'em...(author response	required)

Will be reissued shortly, we are completing some research that was needed to reply to comments.

On Nov 15, 2010, at 15:32 PM, Stephen Farrell wrote:

> 19-Nov-2008,draft-irtf-dtnrg-udp-clayer

Hans Kruse, Professor
J. Warren McClure School of Information and Telecommunication Systems
Adjunct Associate Professor of Electrical Engineering and Computer Science
Chief Operating Officer, GRID Lab
292 Lindley Hall, Ohio University, Athens, OH, 45701
740-593-4891 voice, 740-593-4889 fax

Date: Mon, 15 Nov 2010 17:19:05 -0500
From: Daniel Ellard <[email-masked]>
Organization: BBN Technologies
To: [email-masked]
Subject: Re: [dtn-interest] Moving I-Ds along or killing 'em...(author response required)

On 11/15/10 3:32 PM, Stephen Farrell wrote:
> 
> Hi all,
> 
> All (or almost all) those DTN related I-Ds are presumably
> intended to become RFCs. There's a big bunch so I want to
> put some manners on the set, in terms of when we plan to
> get done with each.
> 
> I've sorted the on-line list into various states, some of
> which I've just invented but all of which should be obvious
> for anyone familiar with IETF or IRTF processes. The
> full list is below.

> 10. Almost certainly dead (just checking)
> 
> 24-Feb-2010,draft-ellard-dtnrg-reltime-htl

Dead.

I'm not sure which of these is the one that superseded it,
and I want to make sure that someone is pushing forward on
that.  (Dan Brown, who was working on it, has moved on to
other pursuits, and I'm not sure whether he's even on this
list any more)

-Dan

-- 
Daniel Ellard, Ph.D.
Senior Scientist, Network Research
BBN Technologies
10 Moulton Street
Cambridge, MA 02138
[email-masked]

From: <[email-masked]>
To: <[email-masked]>
Date: Mon, 15 Nov 2010 21:13:06 +0000
Accept-Language: en-US, en-GB
acceptlanguage: en-US, en-GB
Cc: [email-masked]
Subject: Re: [dtn-interest] Moving I-Ds along or killing 'em...(author response	required)

> 6. work-in-progress, "accepted" by RG
>
> 14-Nov-2010,draft-irtf-dtnrg-bundle-checksum

just reissued. Heavily dependent on the draft-irtf-dtnrg-bundle-security draft; unlikely to move along until that (and its terminology...) is finalized, at which point it moves to 5 last call.

> 14-Nov-2010,draft-wood-dtnrg-saratoga

just reissued. Dependent on draft-wood-tsvwg-saratoga; unlikely to move along until that's finalized, at which point it moves to 5 last call.

> 14-Nov-2010,draft-wood-dtnrg-http-dtn-delivery

just reissued. Given that the Beijing session minutes (and thanks for being timely with those. A welcome surprise.) state that there's interest doing http over bundling - something we looked at internally in quite some detail back in 2008, before entirely discarding several approaches to that and coming up with this draft outlining a better, simpler approach to dealing with http - it may be that the approach in this draft will finally get the attention it deserves, at which point it gets adopted as a research group draft. More at:
http://sat-net.com/L.Wood/dtn/http-dtn
Inspection will show that this beats belatedly kludging a MIMEtype into the bundle protocol, trying to map streaming to bundles, etc. 

> 10. Almost certainly dead (just checking)
>
> 14-Aug-2007,draft-eddy-dtnrg-checksum

We reworked the approach in that for the irtf bundle checksum draft, so this one is OBE.

material related to all of these is available at
http://sat-net.com/L.Wood/dtn

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: Stephen Farrell <[email-masked]>
Date: Mon, 15 Nov 2010 15:09:53 -0600
Accept-Language: en-US
acceptlanguage: en-US
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] Moving I-Ds along or killing 'em...(author response	required)

Certainly Dead.  If someone wants to take it over, they are certainly welcome to do so.

- Will

On Nov 15, 2010, at 3:32 PM, Stephen Farrell wrote:

> 06-Jun-2009,draft-ivancic-dtnrg-network-management-reqs

******************************
William D. Ivancic
Phone 216-433-3494
Fax 216-433-8705
Networking Lab 216-433-2620
DTN Lab 216-433-2981
Mobile 440-503-4892
http://roland.grc.nasa.gov/~ivancic

Date: Mon, 15 Nov 2010 20:43:21 +0000
From: Stephen Farrell <[email-masked]>
To: Stephen Farrell <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] Moving I-Ds along or killing 'em...(author response required)

My guesses for things for which I'm an author:

- draft-irtf-bundle-age-block, 6->5 once someone
writes code, maybe 6 months or so, I'll help

- draft-irtf-dtnrg-sec-overview, 6->5 once the
BSP is actually an RFC, maybe take two revs to
be done, I'll work on i

- draft-farrell-dtnrg-bpq, 7-> 6, that can
happen now I think if folks are ok with it, I'll
work on it (we're starting to code it up now)

- draft-farrell-dtnrg-km, 9->8, I've tried a
few times, but no-one seems to have cycles to
do work on this

S.

PS: for documents with >1 author, its ok to get
>1 response (more is better:-)

On 15/11/10 20:32, Stephen Farrell wrote:
> 
> Hi all,
> 
> All (or almost all) those DTN related I-Ds are presumably
> intended to become RFCs. There's a big bunch so I want to
> put some manners on the set, in terms of when we plan to
> get done with each.
> 
> I've sorted the on-line list into various states, some of
> which I've just invented but all of which should be obvious
> for anyone familiar with IETF or IRTF processes. The
> full list is below.
> 
> Can document authors please reply to this mail with your
> plans for state changes for your documents? If I hear nothing,
> I'm gonna treat 'em as OBE or "probably dead."
> 
> In each case, please clearly say which I-D, (just give
> the name), which state change (e.g. "7->6") you think
> is next, when you think that could happen (e.g. "in
> about two months") with realism being appreciated, and
> if the new state is not OBE or dead, (i.e. 8, 9 or
> 10), then please also give an assurance that you have
> the time available for moving the document forward.
> 
> Negative information is also welcome, e.g. saying
> "would like draft-foo to go from 6->5, think that'd
> take a month or so but I don't have time, so
> suggest transitioning from 6->8"
> 
> And since its a long list, if you spot a plain error,
> just reply with a suggested fix.
> 
> I'd like all responses that imply future work for
> me in the near future by the end of next week please.
> That basically means anything about which I hear
> nothing before November 28 will be treated by me
> as being in one of states 8,9 or 10.
> 
> Once I get all that, I'll try see if there's a
> sensible bunch to send to the IRSG at once, of if
> we just do 'em one at a time.
> 
> Thanks,
> Stephen.
> DTNRG-related I-D status, 2010-11-15
> [email-masked]
> Format is <last-rev-date,I-D-name>
> 
> 1. RFC already
> 
> 25-Jun-2008,draft-irtf-dtnrg-ltp-extensions
> 25-Jun-2008,draft-irtf-dtnrg-ltp-motivation
> 25-Jun-2008,draft-irtf-dtnrg-ltp
> 05-Jul-2007,draft-irtf-dtnrg-bundle-spec
> 15-Dec-2006,draft-irtf-dtnrg-arch
> 
> 2. RFC editor queue
> 
> Nothing
> 
> 3. IESG "end-run" review
> (Actually, I've not yet asked, gotta assemble the
> electronic paperwork in the next few days.)
> 
> 11-Nov-2010,draft-irtf-dtnrg-cbhe
> 25-Oct-2010,draft-irtf-dtnrg-prophet
> 25-Oct-2010,draft-irtf-dtnrg-iana-bp-registries
> 11-Oct-2010,draft-irtf-dtnrg-sdnv
> 13-Sep-2010,draft-irtf-dtnrg-bundle-security
> 08-Jul-2010,draft-irtf-dtnrg-bundle-metadata-block
> 
> 4. IRSG review
> 
> Nothing
> 
> 5. DTNRG "last-call-like-state"
> 
> Nothing
> 
> 6. work-in-progress, "accepted" by RG
> 
> 14-Nov-2010,draft-irtf-dtnrg-bundle-checksum
> 11-Nov-2010,draft-irtf-dtnrg-ecos
> 25-Oct-2010,draft-irtf-dtnrg-bundle-age-block
> 17-May-2010,draft-irtf-dtnrg-bundle-previous-hop-block
> 08-Mar-2010,draft-irtf-dtnrg-ipnd
> 09-Feb-2010,draft-irtf-dtnrg-ding-network-management
> 05-Oct-2009,draft-irtf-dtnrg-bundle-retrans-block
> 12-Aug-2009,draft-irtf-dtnrg-bundle-divert
> 12-Aug-2009,draft-irtf-dtnrg-bundle-encapsulation
> 31-Mar-2009,draft-irtf-dtnrg-dtn-uri-scheme
> 09-Mar-2009,draft-irtf-dtnrg-sec-overview
> 09-Mar-2009,draft-irtf-dtnrg-bundle-eidrefs
> 09-Mar-2009,draft-irtf-dtnrg-bundle-metadata-conf
> 19-Nov-2008,draft-irtf-dtnrg-udp-clayer
> 03-Nov-2008,draft-irtf-dtnrg-tcp-clayer
> 
> 7. work-in-progress (individual)
> 
> 14-Nov-2010,draft-wood-dtnrg-saratoga
> 14-Nov-2010,draft-wood-dtnrg-http-dtn-delivery
> 08-Nov-2010,draft-uehara-dtnrg-decentralized-probe-message
> 08-Nov-2010,draft-uehara-dtnrg-decentralized-probe-transport
> 08-Nov-2010,draft-farrell-dtnrg-bpq
> 20-Aug-2010,draft-burleigh-dtnrg-ltpcl
> 09-Jul-2010,draft-burleigh-dtnrg-cgr
> 28-Feb-2010,draft-fall-dtnrg-schl
> 27-Feb-2010,draft-mcmahon-dtnrg-dtn-edp
> 26-Oct-2009,draft-davies-dtnrg-uri-find
> 
> 8. Overtaken by events (OBE)
> 
> Nothing
> 
> 9. Probably dead (maybe worth reviving?)
> 
> 22-May-2009,draft-pbasu-dtnrg-naming
> 19-Jun-2007,draft-farrell-dtnrg-km
> 17-Apr-2007,draft-kutscher-dtnrg-uni-clayer
> 18-Nov-2007,draft-wyllie-dtnrg-badisc
> 13-Nov-2007,draft-ott-dtnrg-dtn-appl
> 26-May-2006,draft-eddy-dtnrg-eid
> 
> 10. Almost certainly dead (just checking)
> 
> 22-Mar-2010,draft-blanchet-dtnrg-iana-registries
> 24-Feb-2010,draft-ellard-dtnrg-reltime-htl
> 23-Nov-2009,draft-farrell-dtnrg-alt-time
> 12-Aug-2009,draft-symington-dtnrg-bundle-multicast-custodial
> 06-Jun-2009,draft-ivancic-dtnrg-network-management-reqs
> 08-Feb-2008,draft-symington-dtnrg-bundle-metadata-block
> 14-Aug-2007,draft-eddy-dtnrg-checksum
> 29-May-2007,draft-lindgren-dtnrg-prophet
> 18-Oct-2006,draft-demmer-dtnrg-tcp-clayer
> 13-Oct-2006,draft-symington-dtnrg-bundle-retrans-block
> 27-Oct-2003,draft-irtf-dtnrg-ipn-bundle-xfer
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

Date: Mon, 15 Nov 2010 20:32:37 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] Moving I-Ds along or killing 'em...(author response required)

Hi all,

All (or almost all) those DTN related I-Ds are presumably
intended to become RFCs. There's a big bunch so I want to
put some manners on the set, in terms of when we plan to
get done with each.

I've sorted the on-line list into various states, some of
which I've just invented but all of which should be obvious
for anyone familiar with IETF or IRTF processes. The
full list is below.

Can document authors please reply to this mail with your
plans for state changes for your documents? If I hear nothing,
I'm gonna treat 'em as OBE or "probably dead."

In each case, please clearly say which I-D, (just give
the name), which state change (e.g. "7->6") you think
is next, when you think that could happen (e.g. "in
about two months") with realism being appreciated, and
if the new state is not OBE or dead, (i.e. 8, 9 or
10), then please also give an assurance that you have
the time available for moving the document forward.

Negative information is also welcome, e.g. saying
"would like draft-foo to go from 6->5, think that'd
take a month or so but I don't have time, so
suggest transitioning from 6->8"

And since its a long list, if you spot a plain error,
just reply with a suggested fix.

I'd like all responses that imply future work for
me in the near future by the end of next week please.
That basically means anything about which I hear
nothing before November 28 will be treated by me
as being in one of states 8,9 or 10.

Once I get all that, I'll try see if there's a
sensible bunch to send to the IRSG at once, of if
we just do 'em one at a time.

Thanks,
Stephen.
DTNRG-related I-D status, 2010-11-15
[email-masked]
Format is <last-rev-date,I-D-name>

1. RFC already

25-Jun-2008,draft-irtf-dtnrg-ltp-extensions
25-Jun-2008,draft-irtf-dtnrg-ltp-motivation
25-Jun-2008,draft-irtf-dtnrg-ltp
05-Jul-2007,draft-irtf-dtnrg-bundle-spec
15-Dec-2006,draft-irtf-dtnrg-arch

2. RFC editor queue

Nothing

3. IESG "end-run" review
(Actually, I've not yet asked, gotta assemble the
electronic paperwork in the next few days.)

11-Nov-2010,draft-irtf-dtnrg-cbhe
25-Oct-2010,draft-irtf-dtnrg-prophet
25-Oct-2010,draft-irtf-dtnrg-iana-bp-registries
11-Oct-2010,draft-irtf-dtnrg-sdnv
13-Sep-2010,draft-irtf-dtnrg-bundle-security
08-Jul-2010,draft-irtf-dtnrg-bundle-metadata-block

4. IRSG review

Nothing

5. DTNRG "last-call-like-state"

Nothing

6. work-in-progress, "accepted" by RG

14-Nov-2010,draft-irtf-dtnrg-bundle-checksum
11-Nov-2010,draft-irtf-dtnrg-ecos
25-Oct-2010,draft-irtf-dtnrg-bundle-age-block
17-May-2010,draft-irtf-dtnrg-bundle-previous-hop-block
08-Mar-2010,draft-irtf-dtnrg-ipnd
09-Feb-2010,draft-irtf-dtnrg-ding-network-management
05-Oct-2009,draft-irtf-dtnrg-bundle-retrans-block
12-Aug-2009,draft-irtf-dtnrg-bundle-divert
12-Aug-2009,draft-irtf-dtnrg-bundle-encapsulation
31-Mar-2009,draft-irtf-dtnrg-dtn-uri-scheme
09-Mar-2009,draft-irtf-dtnrg-sec-overview
09-Mar-2009,draft-irtf-dtnrg-bundle-eidrefs
09-Mar-2009,draft-irtf-dtnrg-bundle-metadata-conf
19-Nov-2008,draft-irtf-dtnrg-udp-clayer
03-Nov-2008,draft-irtf-dtnrg-tcp-clayer

7. work-in-progress (individual)

14-Nov-2010,draft-wood-dtnrg-saratoga
14-Nov-2010,draft-wood-dtnrg-http-dtn-delivery
08-Nov-2010,draft-uehara-dtnrg-decentralized-probe-message
08-Nov-2010,draft-uehara-dtnrg-decentralized-probe-transport
08-Nov-2010,draft-farrell-dtnrg-bpq
20-Aug-2010,draft-burleigh-dtnrg-ltpcl
09-Jul-2010,draft-burleigh-dtnrg-cgr
28-Feb-2010,draft-fall-dtnrg-schl
27-Feb-2010,draft-mcmahon-dtnrg-dtn-edp
26-Oct-2009,draft-davies-dtnrg-uri-find

8. Overtaken by events (OBE)

Nothing

9. Probably dead (maybe worth reviving?)

22-May-2009,draft-pbasu-dtnrg-naming
19-Jun-2007,draft-farrell-dtnrg-km
17-Apr-2007,draft-kutscher-dtnrg-uni-clayer
18-Nov-2007,draft-wyllie-dtnrg-badisc
13-Nov-2007,draft-ott-dtnrg-dtn-appl
26-May-2006,draft-eddy-dtnrg-eid

10. Almost certainly dead (just checking)

22-Mar-2010,draft-blanchet-dtnrg-iana-registries
24-Feb-2010,draft-ellard-dtnrg-reltime-htl
23-Nov-2009,draft-farrell-dtnrg-alt-time
12-Aug-2009,draft-symington-dtnrg-bundle-multicast-custodial
06-Jun-2009,draft-ivancic-dtnrg-network-management-reqs
08-Feb-2008,draft-symington-dtnrg-bundle-metadata-block
14-Aug-2007,draft-eddy-dtnrg-checksum
29-May-2007,draft-lindgren-dtnrg-prophet
18-Oct-2006,draft-demmer-dtnrg-tcp-clayer
13-Oct-2006,draft-symington-dtnrg-bundle-retrans-block
27-Oct-2003,draft-irtf-dtnrg-ipn-bundle-xfer

From: "Ruhai Wang" <[email-masked]>
To: "'Stephen Farrell'" <[email-masked]>, "'DTN'" <[email-masked]>
Date: Mon, 15 Nov 2010 14:12:23 -0500 (EST)
Subject: Re: [dtn-interest] IETF-79 session draft minutes

This is a multi-part message in MIME format.

------=_NextPart_000_00B1_01CB84C6.BD4A3820
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Dear Colleagues:

I am sorry that Dr. Zhang of my group in China couldn't make the
presentation at the meeting due to some emergency. The presentation was
entitled "Overview of Current Space DTN Activities in China". It discusses
some of the current work on DTN for Space as part of in advance research
needed for China's Moon probing/landing and Mars probing projects in the
next 10~20 years. For your convenience, attached please find its PPT
slides (in PDF). Please feel free to contact us if you have any question
or comments on our work. 

Stephen: thanks for the help in going over it quickly!

Best regards,

Ruhai
*************************************
Ruhai Wang, Ph.D.
Associate Professor
Graduate Coordinator
Drayer Department of Electrical Engineering
Lamar University
P.O. Box 10029
Beaumont, Texas 77710
*************************************
Phone:(409) 880-1829
Fax:    (409) 880-1821
Email:  [email-masked]

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
Stephen Farrell
Sent: Monday, November 15, 2010 11:57 AM
To: DTN
Subject: [dtn-interest] IETF-79 session draft minutes

In a break with tradition, I've promptly posted draft
minutes [1] from the DTNRG session in Beijing.

Send me changes as required.

Thanks,
Stephen.

[1] http://www.ietf.org/proceedings/79/minutes/DTNRG.txt

_______________________________________________
dtn-interest mailing list
[email-masked]
http://maillists.intel-research.net/mailman/listinfo/dtn-interest

CONFIDENTIALITY: Any information contained in this e-mail 
(including attachments) is the property of The State of Texas and 
unauthorized disclosure or use is prohibited. Sending, receiving or 
forwarding of confidential, proprietary and privileged information is 
prohibited under Lamar Policy. If you received this e-mail in error, 
please notify the sender and delete this e-mail from your system.

------=_NextPart_000_00B1_01CB84C6.BD4A3820
Content-Type: application/pdf;
	name="Overview of Current Space DTN Activities in China.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="Overview of Current Space DTN Activities in China.pdf"

------=_NextPart_000_00B1_01CB84C6.BD4A3820--

Date: Mon, 15 Nov 2010 17:57:23 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] IETF-79 session draft minutes

In a break with tradition, I've promptly posted draft
minutes [1] from the DTNRG session in Beijing.

Send me changes as required.

Thanks,
Stephen.

[1] http://www.ietf.org/proceedings/79/minutes/DTNRG.txt

Date: Mon, 15 Nov 2010 17:09:04 +0100
From: Johannes Morgenroth <[email-masked]>
To: [email-masked], DTN <[email-masked]>
Subject: [dtn-interest] [ibr-dtn]  IBR-DTN release 0.4.3

  Hi.

We got a new release of IBR-DTN!

ChangeLog:
- Use Netlink Library for interface to address resolving
- Epidemic routing improved
- Friendly error messages in tools
- Improved dtnping with reply and timeout checking
- TCP convergence layer reconnect after a connection failure
- Help output for daemon added
- TCP tuning options added (segment size & nodelay)
- Improved API and TCPCL connections
- API support unix domain sockets
- Added flooding as routing option
- Purge vector exchange added to epidemic routing
- DNS resolving for names of static tcp connections
- IPv6 support for outgoing TCP connections
- Fixed deletion of non-existing file in the storage caused a crash
- Improved flow control and error correction in epidemic routing
- Discovery timeout is configurable now (discovery_timeout)

For more information visit this page:
http://www.ibr.cs.tu-bs.de/projects/ibr-dtn/

Regards,
Johannes

-- 
Johannes Morgenroth     Institut fuer Betriebssysteme und Rechnerverbund
Tel.: +49-531-391-3249                           Muehlenpfordtstrasse 23
Fax.: +49-531-391-5936      TU Braunschweig         D-38106 Braunschweig

From: Ioannis Komnios <[email-masked]>
Date: Mon, 15 Nov 2010 14:58:53 +0200
To: [email-masked], [email-masked], [email-masked]
Subject: [dtn-interest] WWIC 2011 - "9th International Conference on Wired/Wireless Internet Communications"

--Apple-Mail-13-133604428
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

-=
--------------------------------------------------------------------------=
-------------------
-                Our apologies if you receive multiple copies of this =
CFP            -
=
--------------------------------------------------------------------------=
--------------------

                                         CALL FOR PAPERS

                                              WWIC 2011
                                9th International Conference on=20
                       Wired/Wireless Internet Communications

                            http://www.craax.upc.edu/WWIC11
                           =20
                                        June 15-17, 2011
                         Vilanova i la Geltr=C3=BA, Barcelona, Spain

=
--------------------------------------------------------------------------=
-------------------

****               SUBMISSION DEADLINE: JANUARY 20, 2011              =
*******

=
--------------------------------------------------------------------------=
-------------------

Next generation mobile networks will be based on Internet core networks =
and=20
wireless access networks. The need for efficient merging of the wired =
and wireless
infrastructure as well as the new multimedia services and applications =
of next
generation networks call for novel network architectures, protocols and
traffic-related mechanisms, merging and assembling different network
technologies features. WWIC addresses research topics such as the design =
and
evaluation of protocols, the dynamics of the integration, the =
performance
tradeoffs, the need for new performance metrics, and cross-layer =
interactions.
The goal of the conference is to present high-quality results in the =
field,=20
and to provide a framework for research collaboration through focused =
discussions
that will designate future research efforts and directions. In this =
context,=20
the program committee will accept only a limited number of papers that =
meet=20
the criteria of originality, presentation quality and topic relevance.=20=

WWIC is a single-track conference which has reached, within 8 years, the=20=

highest level of quality, which is reflected both in the level of =
participation=20
as well as the acceptance ratio and the amount and quality of submitted =
papers.
Accepted papers will appear in the conference proceedings published by =
Springer=20
in the Lecture Notes of Computer Science (LNCS) Series. Extended =
versions of conference
selected papers will be considered for publication in an special issue =
of an
international journal.

Following the conference tradition there will also be a Best Paper =
Award.

Topics of interest include, but are not limited to:

- AAA in mobile environments
- Ambient networks
- Ad-hoc mobile networks
- Blended network configurations
- Beyond 3G networks technologies
- Cross layer interactions
- Economical issues of wireless networks
 -End-to-end Quality of Service support
- Handover techniques
- Heterogeneous wireless access networks
- Hybrid wired / wireless environments
- Interaction wireless/optical networks
- Integration of wired and wireless networks
- Mobile service level agreements/spec.
- Mobility management
- Network design and network planning
- Network mobility
- Network coding in mobile networks
- Network security in mobile environments
- Performance evaluation of wireless systems
- Pricing, charging and accounting in wireless net.
- QoS routing in mobile networks
- QoS signalling in mobile environments
- Resource management and admission control
- Service creation and management for wireless
- Simulation for next generation mobile networks
- Traffic characterization and modeling
- Traffic engineering
- Transport protocols and congestion control
- Wireless mesh networks
- Wireless multi-hop networks
- Wireless multimedia systems
- Wireless network monitoring
- Wireless sensor networks
- Optical/Wireless integration
- Space internetworking
- Delay/disruptive tolerant networking
- Vehicular networks

PAPER SUBMISSION AND PUBLICATION
------------------------------------------------------------------------
All submissions must describe original research, not published or=20
currently under review for another workshop, conference, or journal.=20
Papers must be submitted electronically through EDAS.
You can find detailed submission instructions at=20
http://www.craax.upc.edu/WWIC11

*******************
Submission implies the willingness of at least one author to attend
the conference and present the paper. Accepted papers will appear
in the conference proceedings published by Springer in the
Lecture Notes of Computer Science (LNCS) Series.
*******************

IMPORTANT DATES
------------------------------------------------------------------------
- Manuscript submission deadline:      January 20, 2011.
- Manuscript acceptance notification:  March 4, 2011.

CONTACTS
------------------------------------------------------------------------
For further information, please visit the conference website at
http://www.craax.upc.edu/WWIC11 or contact the TPC-chairs
at [email-masked]

WORKSHOPS AND AFFILIATED EVENTS:
------------------------------------------------------------------------
Two workshops will be held in conjunction with the main conference.

5th ERCIM eMobility Workshop on June 14, 2011
4th IntelliCIS Workshop on June 13-14, 2011

Please visit the conference website for details.

ORGANIZING COMMITTEE
------------------------------------------------------------------------
GENERAL CO-CHAIRS
Xavier Masip-Bruin, Universitat Polit=C3=A8cnica de Catalunya, UPC, =
Spain
Dominique Verchere, Alcatel-Lucent Bell Labs, France

TPC CO-CHAIRS
Vassilis Tsaoussidis, Democritus University of Thrace, Greece
Marcelo Yannuzzi, Universitat Polit=C3=A8cnica de Catalunya, UPC, Spain

PUBLICATION CO-CHAIRS
Eva Mar=C3=ADn-Tordera, Universitat Polit=C3=A8cnica de Catalunya, UPC, =
Spain

PUBLICITY CO-CHAIRS
Eduardo Cerqueira, UFPA, Brazil
Alex Sprintson, Texas A&M, USA

STEERING COMMITTEE
Torsten Barun, University of Bern, Switzerland
Georg Carle, TU M=C3=BCnchen, Germany
Geert Heijenk, University of Twente, The Netherlands
Yevgeni Koucheryavy, Tampere University of Technology, Finland
Peter Langend=C3=B6rfer, IHP Microelectronics, Germany
Ibrahim Matta, Boston University, USA
Vassilis Tsaoussidis, Democritus University of Thrace, Greece

SPONSORED BY:
Cisco
Spice=20
COST Program
UPC
Neapoli

--Apple-Mail-13-133604428
Content-Type: multipart/mixed;
	boundary=Apple-Mail-14-133604428

--Apple-Mail-14-133604428
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><pre =
wrap=3D""><font class=3D"Apple-style-span" face=3D"Helvetica" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: =
14px;">-------------------------------------------------------------------=
---------------------------
-                Our apologies if you receive multiple copies of this =
CFP            -
=
--------------------------------------------------------------------------=
--------------------

                                         CALL FOR PAPERS

                                              WWIC 2011
                                9th International Conference on=20
                       Wired/Wireless Internet Communications

</span></font></pre><div align=3D"left">&nbsp;&nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp;<a =
href=3D"http://www.craax.upc.edu/WWIC11">http://www.craax.upc.edu/WWIC11</=
a><br></div><pre wrap=3D""><font class=3D"Apple-style-span" =
face=3D"Helvetica" size=3D"4"><span class=3D"Apple-style-span" =
style=3D"font-size: 14px;">                           =20
                                        June 15-17, 2011
                         Vilanova i la Geltr=C3=BA, Barcelona, Spain

=
--------------------------------------------------------------------------=
-------------------

****               SUBMISSION DEADLINE: JANUARY 20, 2011              =
*******

=
--------------------------------------------------------------------------=
-------------------

</span></font></pre><pre><span lang=3D"EN-US"><font =
class=3D"Apple-style-span" face=3D"Helvetica" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 14px;">Next generation =
mobile networks will be based on Internet core networks and=20
wireless access networks. The need for efficient merging of the wired =
and wireless
infrastructure as well as the new multimedia services and applications =
of next
generation networks call for novel network architectures, protocols and
traffic-related mechanisms, merging and assembling different network
technologies features. WWIC addresses research topics such as the design =
and
evaluation of protocols, the dynamics of the integration, the =
performance
tradeoffs, the need for new performance metrics, and cross-layer =
interactions.<o:p></o:p></span></font></span></pre><pre><span =
lang=3D"EN-US"><font class=3D"Apple-style-span" face=3D"Helvetica" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: =
14px;">The goal of the conference is to present high-quality results in =
the field,=20
and to provide a framework for research collaboration through focused =
discussions
that will designate future research efforts and directions. In this =
context,=20
the program committee will accept only a limited number of papers that =
meet=20
the criteria of originality, presentation quality and topic relevance.=20=

WWIC is a single-track conference which has reached, within 8 years, the=20=

highest level of quality, which is reflected both in the level of =
participation=20
as well as the acceptance ratio and the amount and quality of submitted =
papers.<o:p></o:p></span></font></span></pre><pre wrap=3D""><span =
lang=3D"EN-US"><font class=3D"Apple-style-span" face=3D"Helvetica" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: =
14px;">Accepted papers will appear in the conference proceedings =
published by Springer=20
in the Lecture Notes of Computer Science (LNCS) Series. Extended =
versions of conference
selected papers will be considered for publication in an special issue =
of an
international journal.

Following the conference tradition there will also be a Best Paper =
Award.

</span></font></span><font class=3D"Apple-style-span" face=3D"Helvetica" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: =
14px;">Topics of interest include, but are not limited to:

</span></font><big><big><span lang=3D"EN-US"><big><font =
class=3D"Apple-style-span" face=3D"Helvetica" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 14px;">- AAA in mobile =
environments</span></font></big><font class=3D"Apple-style-span" =
face=3D"Helvetica">
-</font><big><font class=3D"Apple-style-span" face=3D"Helvetica" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: 14px;"> =
Ambient networks
- Ad-hoc mobile networks
- Blended network configurations
- Beyond 3G networks technologies
- Cross layer interactions
- Economical issues of wireless networks
 -End-to-end Quality of Service support
- Handover techniques
- Heterogeneous wireless access networks
- Hybrid wired / wireless environments
- Interaction wireless/optical networks
- Integration of wired and wireless networks
- Mobile service level agreements/spec.
- Mobility management
- Network design and network planning
- Network mobility
- Network coding in mobile networks
- Network security in mobile environments
- Performance evaluation of wireless systems
- Pricing, charging and accounting in wireless net.
- QoS routing in mobile networks
- QoS signalling in mobile environments
- Resource management and admission control
- Service creation and management for wireless
- Simulation for next generation mobile networks
- Traffic characterization and modeling
- Traffic engineering
- Transport protocols and congestion control
- Wireless mesh networks
- Wireless multi-hop networks
- Wireless multimedia systems
- Wireless network monitoring
- Wireless sensor networks
- Optical/Wireless integration
- Space internetworking
- Delay/disruptive tolerant networking
- Vehicular networks
</span></font></big></span></big></big><font class=3D"Apple-style-span" =
face=3D"Helvetica" size=3D"4"><span class=3D"Apple-style-span" =
style=3D"font-size: 14px;">

PAPER SUBMISSION AND PUBLICATION
------------------------------------------------------------------------
All submissions must describe original research, not published or=20
currently under review for another workshop, conference, or journal.=20
Papers must be submitted electronically through EDAS.
You can find detailed submission instructions at=20
</span></font><a href=3D"http://www.craax.upc.edu/WWIC11"><font =
class=3D"Apple-style-span" face=3D"Helvetica" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: =
14px;">http://www.craax.upc.edu/WWIC11</span></font></a><font =
class=3D"Apple-style-span" face=3D"Helvetica" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 14px;">

*******************
Submission implies the willingness of at least one author to attend
the conference and present the paper. Accepted papers will appear
in the conference proceedings published by Springer in the
Lecture Notes of Computer Science (LNCS) Series.
*******************

IMPORTANT DATES
------------------------------------------------------------------------
- Manuscript submission deadline:      January 20, 2011.
- Manuscript acceptance notification:  March 4, 2011.

CONTACTS
------------------------------------------------------------------------
For further information, please visit the conference website at
</span></font><a href=3D"http://www.craax.upc.edu/WWIC11"><font =
class=3D"Apple-style-span" face=3D"Helvetica" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: =
14px;">http://www.craax.upc.edu/WWIC11</span></font></a><font =
class=3D"Apple-style-span" face=3D"Helvetica" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 14px;"> or contact the =
TPC-chairs
at </span></font><a class=3D"moz-txt-link-abbreviated" =
href=3D"mailto:[email-masked]"><font class=3D"Apple-style-span" =
face=3D"Helvetica" size=3D"4"><span class=3D"Apple-style-span" =
style=3D"font-size: 14px;">[email-masked]</span></font></a><font =
class=3D"Apple-style-span" face=3D"Helvetica" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 14px;">

WORKSHOPS AND AFFILIATED EVENTS:
------------------------------------------------------------------------
Two workshops will be held in conjunction with the main conference.

5th ERCIM eMobility Workshop on June 14, 2011
4th IntelliCIS Workshop on June 13-14, 2011

Please visit the conference website for details.

ORGANIZING COMMITTEE
------------------------------------------------------------------------
GENERAL CO-CHAIRS
Xavier Masip-Bruin, Universitat Polit=C3=A8cnica de Catalunya, UPC, =
Spain
Dominique Verchere, Alcatel-Lucent Bell Labs, France

TPC CO-CHAIRS
Vassilis Tsaoussidis, Democritus University of Thrace, Greece
Marcelo Yannuzzi, Universitat Polit=C3=A8cnica de Catalunya, UPC, Spain

PUBLICATION CO-CHAIRS
Eva Mar=C3=ADn-Tordera, Universitat Polit=C3=A8cnica de Catalunya, UPC, =
Spain

PUBLICITY CO-CHAIRS
Eduardo Cerqueira, UFPA, Brazil
Alex Sprintson, Texas A&amp;M, USA

STEERING COMMITTEE
Torsten Barun, University of Bern, Switzerland
Georg Carle, TU M=C3=BCnchen, Germany
Geert Heijenk, University of Twente, The Netherlands
Yevgeni Koucheryavy, Tampere University of Technology, Finland
Peter Langend=C3=B6rfer, IHP Microelectronics, Germany
Ibrahim Matta, Boston University, USA
Vassilis Tsaoussidis, Democritus University of Thrace, Greece

SPONSORED BY:
Cisco
Spice=20
COST Program
UPC
Neapoli</span></font></pre><div></div></body></html>=

--Apple-Mail-14-133604428
Content-Disposition: inline;
	filename=CFP_WWIC2011.pdf
Content-Type: application/pdf;
	x-unix-mode=0644;
	name="CFP_WWIC2011.pdf"
Content-Transfer-Encoding: base64

--Apple-Mail-14-133604428
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div></div></body></html>
--Apple-Mail-14-133604428--

--Apple-Mail-13-133604428--

Date: Mon, 08 Nov 2010 05:12:38 +0000
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] new I-D: bundle protocol query extension block

Hi Brenton,

On 08/11/10 03:33, [email-masked] wrote:
> Hi Stephen,
>     This is kind-of a superficial question, but to check my understanding;
> For a bundle to be eligible to be queried it must have a response-type
> BPQ block, right?

Its a good question actually. In terms of what we're planning to code
up (for now at least), the answer would be "yes." However, I have
thought a little of how a different matching rule might enable a node
to match bundles it has that don't have a bpq block. (I've not figured
out the details, but I suspect one could.)

>     Also, would this be a legitimate way for an application on a node to
> check the contents of its own data store, 

Sure, I guess so. Not sure what you'd be checking for though.

> or do you think that should
> be handled through a more direct API?

Again, depends on what you're checking for I guess. We've not gotten
as far as figuring out how to implement this in DTN2 btw, that's just
starting now.

Cheers,
S.

> 
> Thanks,
> Brenton
> 
> 
>>
>> Hi all,
>>
>> We just pushed out an I-D [1] on some stuff we plan to do
>> in the next while.
>>
>> Be interested in comments, since I know it overlaps to
>> some extent with work others have done in the past.
>>
>> Regards,
>> S.
>>
>> [1] http://www.ietf.org/id/draft-farrell-dtnrg-bpq-00.txt
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>
> 
> 
> 

Date: Sun, 7 Nov 2010 21:33:40 -0600
From: [email-masked]
To: "Stephen Farrell" <[email-masked]>
Importance: Normal
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] new I-D: bundle protocol query extension block

Hi Stephen,
    This is kind-of a superficial question, but to check my understanding;
For a bundle to be eligible to be queried it must have a response-type
BPQ block, right?

    Also, would this be a legitimate way for an application on a node to
check the contents of its own data store, or do you think that should
be handled through a more direct API?

Thanks,
Brenton

>
> Hi all,
>
> We just pushed out an I-D [1] on some stuff we plan to do
> in the next while.
>
> Be interested in comments, since I know it overlaps to
> some extent with work others have done in the past.
>
> Regards,
> S.
>
> [1] http://www.ietf.org/id/draft-farrell-dtnrg-bpq-00.txt
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

Date: Mon, 08 Nov 2010 01:56:35 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] new I-D: bundle protocol query extension block

Hi all,

We just pushed out an I-D [1] on some stuff we plan to do
in the next while.

Be interested in comments, since I know it overlaps to
some extent with work others have done in the past.

Regards,
S.

[1] http://www.ietf.org/id/draft-farrell-dtnrg-bpq-00.txt

From: Keiichi SHIMA <[email-masked]>
Date: Thu, 4 Nov 2010 11:07:38 +0900
To: Marshall Eubanks <[email-masked]>
Cc: IMAIKE Masayoshi <[email-masked]>, UEHARA Keisuke <[email-masked]>, [email-masked], SATO Masaaki <[email-masked]>
Subject: Re: [dtn-interest] Inter-vehicle probe system using DTN concept

Dear Marshall Eubanks

On Nov 2, 2010, at 10:24 PM, Marshall Eubanks wrote:

> Can I suggest that, for a new work of this sort, you write a draft problem statement (i.e., what problem needs to be solved) and a draft requirements document (i.e., what functionality does any solution need) ? Without that, I think it will be hard to evaluate whether or not, say, the message format is complete. That will also help a lot in evaluating whether or not existing IETF protocols can be used here. 

You are correct.  Although I am not good at describing that kind of issues clearly, it should be nice if we can have consensus about what kind of issue we are trying to solve.  I will start working on drafting it.

Thank you.
---
Keiichi SHIMA
Research Laboratory, IIJ Innovation Institute  <[email-masked]>
WIDE Project <[email-masked]>

On Nov 2, 2010, at 10:24 PM, Marshall Eubanks wrote:

> Dear Keiichi;
> 
> Can I suggest that, for a new work of this sort, you write a draft problem statement (i.e., what problem needs to be solved) and a draft requirements document (i.e., what functionality does any solution need) ? Without that, I think it will be hard to evaluate whether or not, say, the message format is complete. That will also help a lot in evaluating whether or not existing IETF protocols can be used here. 
> 
> Regards
> Marshall Eubanks 
> 
> On Nov 2, 2010, at 4:35 AM, Keiichi SHIMA wrote:
> 
>> Dear all,
>> 
>> My apologies if I am sending an inappropriate message.
>> 
>> We are recently considering a mechanism for vehicles to communicate each other in a distributed manner based on the DTN concept for (real) traffic probing systems.  We looked for proper WGs in IETF, but it seems there is none.  So we decided to contact the DTNRG first.  If you think we should move to somewhere more appropriate, then please let us know the place.
>> 
>> 
>> Below are the I-Ds we are currently working on.  Since we missed the cut off date, these I-Ds are not available from the IETF site yet.  We will submit them once the tools site re-opens.  If you are interested in these documents, please contact us.
>> 
>> The Message Format for Decentralized Probe Applications for Vehicles
>> http://member.wide.ad.jp/~shima/publications/draft-uehara-dtnrg-decentralized-probe-message.txt
>> 
>> The Transport Protocol for Decentralized Probe Applications for Vehicles
>> http://member.wide.ad.jp/~shima/publications/draft-uehara-dtnrg-decentralized-probe-message.txt
>> 
>> Best Regards,
>> ---
>> Keiichi SHIMA
>> Research Laboratory, IIJ Innovation Institute  <[email-masked]>
>> WIDE Project <[email-masked]>
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>> 
> 
> 

Date: Wed, 03 Nov 2010 12:37:19 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] Another batch of documents to go forward...

Hi all,

We're just done with our current batch of documents (btw, please
do respond to the "last call" thing about prophet - some mail saying
yes/no is valuable for that).

Keith and Scott have asked that we start work on progressing their
ECOS draft, so I'll kick that off real soon now. But before I do,
are there any other drafts that the authors think are finished
enough to start their way to being RFCs? If so, pleas let Kevin
and I know, either on or off list, in the next day or two.

Ta,
Stephen.

Date: Wed, 03 Nov 2010 10:41:12 +0100
From: Aline Carneiro Viana <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] IEEE MASS 2010: Call for Participation and available Tech. Program

[We apologize in advance if you receive multiple copies of this message]

==========================================================================
                             CALL FOR PARTICIPATION

                                  IEEE MASS 2010
                7th IEEE International Conference on Mobile Ad-hoc
                              and Sensor Systems
                        https://mass2010.soe.ucsc.edu/

                  November 8-12, 2010 - San Francisco, CA, USA

Co-sponsored by the IEEE Computer Society Technical Commitee on
Distributed Processing and IEEE Computer Society Technical Commitee on
Simulation

==========================================================================

CONFERENCE SITE:
----------------
The 7th IEEE International Conference on Mobile Ad-hoc and Sensor
Systems (IEEE MASS 2010) will be held at the Hilton San Francisco Airport
in San Francisco, California, USA.

SCOPE:
------
Wireless ad-hoc communication has applications in a variety of
environments, such as conferences, hospitals, battlefields and
disaster-recovery/rescue operations, and is also being actively
investigated as an alternative paradigm for Internet connectivity in
both urban and rural areas. Wireless sensor and actuator networks are
also being deployed for enhancing industrial control processes and
supply-chains, and for various forms of environmental monitoring. The
IEEE MASS 2010 aims at addressing advances in research on multi-hop
ad-hoc and sensor networks, covering topics ranging from technology
issues to applications and test-bed development. Please keep checking
the IEEE MASS 2010 web-space for more information and regular updates.

TECHNICAL PROGRAM:
-----------------
The Technical Program is available at the conference website.

REGISTRATION:
-------------
Registration to IEEE MASS is available at the conference website.

WORKSHOPS:
------------

- The Third Workshop on Mobile Entity Localization and Tracking (MELT)
- The Second Workshop on SCEnarios for Network Evaluation Studies (SCENES)
- The Sixth Workshop on Wireless and Sensor Network Security (WSNS)
- The Fourth Workshop on Enabling Technologies and Standards for Wireless Mesh Networking (MESHTECH)
- The Second International Workshop on Intelligent Vehicular Networks (InVeNet)

ORGANIZATION COMMITTEE:
-----------------------

GENERAL CO-CHAIRS
Mario Gerla, University of California, Los Angeles
Katia Obraczka, University of California, Santa Cruz

PROGRAM CO-CHAIRS
Guohong Cao, Pennsylvania State University
Prasant Mohapatra, University of California, Davis

TPC SUB-AREA CHAIRS
- Protocols and Cross-Layer Technologies
Ahmed Helmy, University of Florida

- Systems, and applications
Chenyang Lu, Washington Unviersity in St. Louis

- Algorithms and theory
Dong Xuan, Ohio State University

- Reliability, security and privacy
Radha Poovendran, University of Washington

WORKSHOP CO-CHAIRS
Cedric Westphal, DoCoMo Labs
Christine Pepin, DoCoMo Labs

DEMO CHAIR
Rajeev Koodli, Starent Networks
Marcelo Dias Amorim, LIP 6, Universite' Paris 6

WEB CHAIR
Venkatesh Rajendran, Wionics

FINANCE AND REGISTRATION CHAIR
Zhen Jiang, West Chester University

PUBLICATION CHAIR
Dajin Wang, Montclair State University

PUBLICITY CHAIR
Aline Carneiro Viana, INRIA

LOCAL ARRANGEMENTS CO-CHAIRS
Kumar Viswanath, NTT Labs
Ignacio Solis, PARC

STEERING COMMITTEE CHAIR
Dharma P. Agrawal, University of Cincinnati

CHAIR OF IEEE TC ON DISTRIBUTED PROCESSING
Jie Wu, US National Science Foundation

CHAIR OF IEEE TC ON SIMULATION
Dave Cavalcanti, Phillips Research

From: Marshall Eubanks <[email-masked]>
Date: Tue, 2 Nov 2010 09:24:48 -0400
To: Keiichi SHIMA <[email-masked]>
Cc: UEHARA Keisuke <[email-masked]>, IMAIKE Masayoshi <[email-masked]>, [email-masked], SATO Masaaki <[email-masked]>
Subject: Re: [dtn-interest] Inter-vehicle probe system using DTN concept

Dear Keiichi;

Can I suggest that, for a new work of this sort, you write a draft problem statement (i.e., what problem needs to be solved) and a draft requirements document (i.e., what functionality does any solution need) ? Without that, I think it will be hard to evaluate whether or not, say, the message format is complete. That will also help a lot in evaluating whether or not existing IETF protocols can be used here. 

Regards
Marshall Eubanks 

On Nov 2, 2010, at 4:35 AM, Keiichi SHIMA wrote:

> Dear all,
> 
> My apologies if I am sending an inappropriate message.
> 
> We are recently considering a mechanism for vehicles to communicate each other in a distributed manner based on the DTN concept for (real) traffic probing systems.  We looked for proper WGs in IETF, but it seems there is none.  So we decided to contact the DTNRG first.  If you think we should move to somewhere more appropriate, then please let us know the place.
> 
> 
> Below are the I-Ds we are currently working on.  Since we missed the cut off date, these I-Ds are not available from the IETF site yet.  We will submit them once the tools site re-opens.  If you are interested in these documents, please contact us.
> 
> The Message Format for Decentralized Probe Applications for Vehicles
> http://member.wide.ad.jp/~shima/publications/draft-uehara-dtnrg-decentralized-probe-message.txt
> 
> The Transport Protocol for Decentralized Probe Applications for Vehicles
> http://member.wide.ad.jp/~shima/publications/draft-uehara-dtnrg-decentralized-probe-message.txt
> 
> Best Regards,
> ---
> Keiichi SHIMA
> Research Laboratory, IIJ Innovation Institute  <[email-masked]>
> WIDE Project <[email-masked]>
> 
> 
> 
> 
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

From: Marshall Eubanks <[email-masked]>
Date: Tue, 2 Nov 2010 09:22:47 -0400
To: Keiichi SHIMA <[email-masked]>
Cc: UEHARA Keisuke <[email-masked]>, IMAIKE Masayoshi <[email-masked]>, [email-masked], SATO Masaaki <[email-masked]>
Subject: Re: [dtn-interest] Inter-vehicle probe system using DTN concept

Dear Keiichi;

Can I suggest that, for a new work of this sort, you write a draft problem statement (i.e., what problem needs to be solved) and a draft requirements document (i.e., what functionality does any solution need) ? Without that, I think it will be hard to evaluate whether or not, say, the message format is complete. That will also help a lot in evaluating whether or not existing IETF protocols can be used here. 

Regards
Marshall Eubanks 

On Nov 2, 2010, at 4:35 AM, Keiichi SHIMA wrote:

> Dear all,
> 
> My apologies if I am sending an inappropriate message.
> 
> We are recently considering a mechanism for vehicles to communicate each other in a distributed manner based on the DTN concept for (real) traffic probing systems.  We looked for proper WGs in IETF, but it seems there is none.  So we decided to contact the DTNRG first.  If you think we should move to somewhere more appropriate, then please let us know the place.
> 
> 
> Below are the I-Ds we are currently working on.  Since we missed the cut off date, these I-Ds are not available from the IETF site yet.  We will submit them once the tools site re-opens.  If you are interested in these documents, please contact us.
> 
> The Message Format for Decentralized Probe Applications for Vehicles
> http://member.wide.ad.jp/~shima/publications/draft-uehara-dtnrg-decentralized-probe-message.txt
> 
> The Transport Protocol for Decentralized Probe Applications for Vehicles
> http://member.wide.ad.jp/~shima/publications/draft-uehara-dtnrg-decentralized-probe-message.txt
> 
> Best Regards,
> ---
> Keiichi SHIMA
> Research Laboratory, IIJ Innovation Institute  <[email-masked]>
> WIDE Project <[email-masked]>
> 
> 
> 
> 
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

Date: Tue, 02 Nov 2010 13:22:11 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: Re: [dtn-interest] DTNRG session in Beijing

Hi All,

I've posted a draft agenda for next week's meeting. [1]

Please let me know if I missed anything or something
should change, or if I messed up some other way:-)

If you've a speaking slot, please try get some version
of your slides to me before the end of this Friday, as
I'll be travelling over the weekend, and since I expect
we'll have some remote attendees, I'd like to get slides
uploaded well in advance.

Cheers,
Stephen.

[1] http://www.ietf.org/proceedings/79/agenda/DTNRG.html

Date: Tue, 02 Nov 2010 13:18:01 +0000
From: Stephen Farrell <[email-masked]>
To: Vint Cerf <[email-masked]>
Cc: IMAIKE Masayoshi <[email-masked]>, UEHARA Keisuke <[email-masked]>, [email-masked], SATO Masaaki <[email-masked]>
Subject: Re: [dtn-interest] Inter-vehicle probe system using DTN concept

On 02/11/10 13:14, Vint Cerf wrote:
> The Consultative Committee on Space Data Systems (CCSDS) has been the
> vehicle through which standardization has been pursued for DTN.

Right. But I guess we're talking different vehicles here:-)

S.

Date: Tue, 2 Nov 2010 09:14:59 -0400
From: Vint Cerf <[email-masked]>
To: Stephen Farrell <[email-masked]>
Cc: IMAIKE Masayoshi <[email-masked]>, UEHARA Keisuke <[email-masked]>, [email-masked], SATO Masaaki <[email-masked]>
Subject: Re: [dtn-interest] Inter-vehicle probe system using DTN concept

The Consultative Committee on Space Data Systems (CCSDS) has been the
vehicle through which standardization has been pursued for DTN.

vint

On Tue, Nov 2, 2010 at 9:01 AM, Stephen Farrell
<[email-masked]> wrote:
>
> Hi,
>
> On 02/11/10 10:45, Keiichi SHIMA wrote:
>> Hello Stephen Farrell,
>>
>> Thank you for your quick response.
>>
>>
>> On Nov 2, 2010, at 6:14 PM, Stephen Farrell wrote:
>>
>>> From a quick look at your drafts however, its not clear
>>> to me that there's that much in common between your current
>>> solution and the type of store-and-forward network that
>>> is typically discussed here. Can you elaborate on why
>>> your drafts (but mostly the transport one) specify a
>>> protocol that is delay or disruption tolerant, and why,
>>> e.g. you didn't feel it would be useful to use the BP?
>>
>> I understand your question.  The reason why we wrote these
>> drafts is that we had to work on this task to make a
>> prototype system in very short term.  And, by chance, we
>> had a similar system we were using before.  We thought that
>> it would be better to disclose the concept of this
>> distributed probe application and start discussion on it
>> before adapting our message exchange mechanism to standardized
>> ways.
>
> I'm all in favour of trying things out in the real world,
> and of learning from those, so I think your approach is a
> fine way to do things. But, I guess Vint's suggestion is a
> good way forward, if you can look into the current set of
> DTN protocols and see what works for your application, and
> what else is needed or needs to be changed, then we should
> be able to make good progress here. For example, I can well
> imagine that a new convergence layer might be called for in
> this case, or that you might need to compress bundles if
> the links can really only handle tiny messages. I think it'd
> be great to get such work written up as internet-drafts.
>
> One note though: DTNRG doesn't produce Internet "standards"
> so if that were your goal then you'd want to be talking to
> the IETF. Here we do DTN research and (slowly;-) produce
> experimental or informational RFCs which are different things
> from standards, and its important to understand that difference.
> If it helps feel free to get in touch for an offline
> conversation about that, or if some of you will be at the
> IETF meeting next week, let's try meet up.
>
> Everything else you said sounds great and for what its worth,
> I'd be happy to help as I can and will be interested to see how
> it works out. (And its ok if that takes a while:-)
>
> Cheers,
> Stephen.
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

Date: Tue, 02 Nov 2010 13:01:39 +0000
From: Stephen Farrell <[email-masked]>
To: Keiichi SHIMA <[email-masked]>
Cc: UEHARA Keisuke <[email-masked]>, IMAIKE Masayoshi <[email-masked]>, [email-masked], SATO Masaaki <[email-masked]>
Subject: Re: [dtn-interest] Inter-vehicle probe system using DTN concept

Hi,

On 02/11/10 10:45, Keiichi SHIMA wrote:
> Hello Stephen Farrell,
> 
> Thank you for your quick response.
> 
> 
> On Nov 2, 2010, at 6:14 PM, Stephen Farrell wrote:
> 
>> From a quick look at your drafts however, its not clear
>> to me that there's that much in common between your current
>> solution and the type of store-and-forward network that
>> is typically discussed here. Can you elaborate on why
>> your drafts (but mostly the transport one) specify a
>> protocol that is delay or disruption tolerant, and why,
>> e.g. you didn't feel it would be useful to use the BP?
> 
> I understand your question.  The reason why we wrote these 
> drafts is that we had to work on this task to make a
> prototype system in very short term.  And, by chance, we
> had a similar system we were using before.  We thought that
> it would be better to disclose the concept of this
> distributed probe application and start discussion on it
> before adapting our message exchange mechanism to standardized
> ways.

I'm all in favour of trying things out in the real world,
and of learning from those, so I think your approach is a
fine way to do things. But, I guess Vint's suggestion is a
good way forward, if you can look into the current set of
DTN protocols and see what works for your application, and
what else is needed or needs to be changed, then we should
be able to make good progress here. For example, I can well
imagine that a new convergence layer might be called for in
this case, or that you might need to compress bundles if
the links can really only handle tiny messages. I think it'd
be great to get such work written up as internet-drafts.

One note though: DTNRG doesn't produce Internet "standards"
so if that were your goal then you'd want to be talking to
the IETF. Here we do DTN research and (slowly;-) produce
experimental or informational RFCs which are different things
from standards, and its important to understand that difference.
If it helps feel free to get in touch for an offline
conversation about that, or if some of you will be at the
IETF meeting next week, let's try meet up.

Everything else you said sounds great and for what its worth,
I'd be happy to help as I can and will be interested to see how
it works out. (And its ok if that takes a while:-)

Cheers,
Stephen.

From: Keiichi SHIMA <[email-masked]>
Date: Tue, 2 Nov 2010 21:17:37 +0900
To: Vint Cerf <[email-masked]>
Cc: UEHARA Keisuke <[email-masked]>, IMAIKE Masayoshi <[email-masked]>, [email-masked], SATO Masaaki <[email-masked]>
Subject: Re: [dtn-interest] Inter-vehicle probe system using DTN concept

Hello,

Thank you for your suggestion.  Yes, we will look into the existing mechanisms and try to find a better way to utilize them as much as possible.  As you said, it should be possible to integrate our application with the existing DTN messaging framework.  We will continue to refine our proposal and will ask your comments again, though it may take some time.

Best Regards,

---
Keiichi SHIMA
Research Laboratory, IIJ Innovation Institute  <[email-masked]>
WIDE Project <[email-masked]>

On Nov 2, 2010, at 7:59 PM, Vint Cerf wrote:

> to the extent you have the time to do it, we would all benefit by
> seeing whether the BP and related protocols can be easily adapted to
> serve your needs. If not, this may tell us whether further evolution
> of BP is needed. Keep in mind that the DTN environment is layered as
> are many of the other Internet-related architectures. That means that
> some functionality you need might be crafted above the basic transport
> capability of the BP protocol and its underlying support such at LTP
> or Prox-1, etc.
> 
> vint cerf
> 
> 
> On Tue, Nov 2, 2010 at 6:45 AM, Keiichi SHIMA <[email-masked]> wrote:
>> Hello Stephen Farrell,
>> 
>> Thank you for your quick response.
>> 
>> 
>> On Nov 2, 2010, at 6:14 PM, Stephen Farrell wrote:
>> 
>>> From a quick look at your drafts however, its not clear
>>> to me that there's that much in common between your current
>>> solution and the type of store-and-forward network that
>>> is typically discussed here. Can you elaborate on why
>>> your drafts (but mostly the transport one) specify a
>>> protocol that is delay or disruption tolerant, and why,
>>> e.g. you didn't feel it would be useful to use the BP?
>> 
>> I understand your question.  The reason why we wrote these drafts is that we had to work on this task to make a prototype system in very short term.  And, by chance, we had a similar system we were using before.  We thought that it would be better to disclose the concept of this distributed probe application and start discussion on it before adapting our message exchange mechanism to standardized ways.
>> 
>> It would have taken some more time if we started modifying the protocols before proposing the idea, because to do that, we need to investigate the existing standard protocols specified in this RG in detail if they can be replacements of our transport mechanisms.
>> 
>>> In other words, why is a new delay-tolerant protocol
>>> needed here, and is the protocol you've specified
>>> actually delay-tolerant?
>> 
>> 
>> So, my position is I am open to adapt our transport mechanisms to any standard DTN protocols as long as the application works.  (For the second question, it is hard for us to answer it... we need experts and that is another reason why we contacted this RG.)
>> 
>> 
>>> My guess is that if for some reason you needed to
>>> use exactly the bits-on-the-wire from your current
>>> I-Ds, then DTNRG would probably not turn out to be a
>>> productive place for discussions.
>> 
>> I fully understand.  As I said, if this topic is acceptable in this RG, then we are OK to modify our specially crafted protocols to more standardized ones.  It is not our intention to insist on the current protocols.
>> 
>> 
>>> However, if what you're interested in is figuring out
>>> how DTN mechanisms might work in vehicular networks,
>>> then this is be a fine place for that discussion.
>> 
>> Yes, this is a big interest of us too.
>> 
>> 
>> Best Regards,
>> ---
>> Keiichi SHIMA
>> Research Laboratory, IIJ Innovation Institute  <[email-masked]>
>> WIDE Project <[email-masked]>
>> 
>> 
>> 
>> 
>> 
>> On Nov 2, 2010, at 6:14 PM, Stephen Farrell wrote:
>> 
>>> 
>>> Hi,
>>> 
>>> Discussion on DTN and vehicular networks is clearly in
>>> scope for DTNRG, so no problem there.
>>> 
>>> From a quick look at your drafts however, its not clear
>>> to me that there's that much in common between your current
>>> solution and the type of store-and-forward network that
>>> is typically discussed here. Can you elaborate on why
>>> your drafts (but mostly the transport one) specify a
>>> protocol that is delay or disruption tolerant, and why,
>>> e.g. you didn't feel it would be useful to use the BP?
>>> In other words, why is a new delay-tolerant protocol
>>> needed here, and is the protocol you've specified
>>> actually delay-tolerant?
>>> 
>>> My guess is that if for some reason you needed to
>>> use exactly the bits-on-the-wire from your current
>>> I-Ds, then DTNRG would probably not turn out to be a
>>> productive place for discussions.
>>> 
>>> However, if what you're interested in is figuring out
>>> how DTN mechanisms might work in vehicular networks,
>>> then this is be a fine place for that discussion.
>>> 
>>> Regards,
>>> S.
>>> 
>>> PS:
>>> 
>>> On 02/11/10 08:35, Keiichi SHIMA wrote:
>>>> Dear all,
>>>> 
>>>> My apologies if I am sending an inappropriate message.
>>>> 
>>>> We are recently considering a mechanism for vehicles to communicate each other in a distributed manner based on the DTN concept for (real) traffic probing systems.  We looked for proper WGs in IETF, but it seems there is none.  So we decided to contact the DTNRG first.  If you think we should move to somewhere more appropriate, then please let us know the place.
>>>> 
>>>> 
>>>> Below are the I-Ds we are currently working on.  Since we missed the cut off date, these I-Ds are not available from the IETF site yet.  We will submit them once the tools site re-opens.  If you are interested in these documents, please contact us.
>>>> 
>>>> The Message Format for Decentralized Probe Applications for Vehicles
>>>> http://member.wide.ad.jp/~shima/publications/draft-uehara-dtnrg-decentralized-probe-message.txt
>>>> 
>>>> The Transport Protocol for Decentralized Probe Applications for Vehicles
>>>> http://member.wide.ad.jp/~shima/publications/draft-uehara-dtnrg-decentralized-probe-message.txt
>>>> 
>>>> Best Regards,
>>>> ---
>>>> Keiichi SHIMA
>>>> Research Laboratory, IIJ Innovation Institute  <[email-masked]>
>>>> WIDE Project <[email-masked]>
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> dtn-interest mailing list
>>>> [email-masked]
>>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>>> 
>> 
>> 
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>> 
> 

Date: Tue, 2 Nov 2010 06:59:22 -0400
From: Vint Cerf <[email-masked]>
To: Keiichi SHIMA <[email-masked]>
Cc: SATO Masaaki <[email-masked]>, UEHARA Keisuke <[email-masked]>, IMAIKE Masayoshi <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] Inter-vehicle probe system using DTN concept

to the extent you have the time to do it, we would all benefit by
seeing whether the BP and related protocols can be easily adapted to
serve your needs. If not, this may tell us whether further evolution
of BP is needed. Keep in mind that the DTN environment is layered as
are many of the other Internet-related architectures. That means that
some functionality you need might be crafted above the basic transport
capability of the BP protocol and its underlying support such at LTP
or Prox-1, etc.

vint cerf

On Tue, Nov 2, 2010 at 6:45 AM, Keiichi SHIMA <[email-masked]> wrote:
> Hello Stephen Farrell,
>
> Thank you for your quick response.
>
>
> On Nov 2, 2010, at 6:14 PM, Stephen Farrell wrote:
>
>> From a quick look at your drafts however, its not clear
>> to me that there's that much in common between your current
>> solution and the type of store-and-forward network that
>> is typically discussed here. Can you elaborate on why
>> your drafts (but mostly the transport one) specify a
>> protocol that is delay or disruption tolerant, and why,
>> e.g. you didn't feel it would be useful to use the BP?
>
> I understand your question.  The reason why we wrote these drafts is that we had to work on this task to make a prototype system in very short term.  And, by chance, we had a similar system we were using before.  We thought that it would be better to disclose the concept of this distributed probe application and start discussion on it before adapting our message exchange mechanism to standardized ways.
>
> It would have taken some more time if we started modifying the protocols before proposing the idea, because to do that, we need to investigate the existing standard protocols specified in this RG in detail if they can be replacements of our transport mechanisms.
>
>> In other words, why is a new delay-tolerant protocol
>> needed here, and is the protocol you've specified
>> actually delay-tolerant?
>
>
> So, my position is I am open to adapt our transport mechanisms to any standard DTN protocols as long as the application works.  (For the second question, it is hard for us to answer it... we need experts and that is another reason why we contacted this RG.)
>
>
>> My guess is that if for some reason you needed to
>> use exactly the bits-on-the-wire from your current
>> I-Ds, then DTNRG would probably not turn out to be a
>> productive place for discussions.
>
> I fully understand.  As I said, if this topic is acceptable in this RG, then we are OK to modify our specially crafted protocols to more standardized ones.  It is not our intention to insist on the current protocols.
>
>
>> However, if what you're interested in is figuring out
>> how DTN mechanisms might work in vehicular networks,
>> then this is be a fine place for that discussion.
>
> Yes, this is a big interest of us too.
>
>
> Best Regards,
> ---
> Keiichi SHIMA
> Research Laboratory, IIJ Innovation Institute  <[email-masked]>
> WIDE Project <[email-masked]>
>
>
>
>
>
> On Nov 2, 2010, at 6:14 PM, Stephen Farrell wrote:
>
>>
>> Hi,
>>
>> Discussion on DTN and vehicular networks is clearly in
>> scope for DTNRG, so no problem there.
>>
>> From a quick look at your drafts however, its not clear
>> to me that there's that much in common between your current
>> solution and the type of store-and-forward network that
>> is typically discussed here. Can you elaborate on why
>> your drafts (but mostly the transport one) specify a
>> protocol that is delay or disruption tolerant, and why,
>> e.g. you didn't feel it would be useful to use the BP?
>> In other words, why is a new delay-tolerant protocol
>> needed here, and is the protocol you've specified
>> actually delay-tolerant?
>>
>> My guess is that if for some reason you needed to
>> use exactly the bits-on-the-wire from your current
>> I-Ds, then DTNRG would probably not turn out to be a
>> productive place for discussions.
>>
>> However, if what you're interested in is figuring out
>> how DTN mechanisms might work in vehicular networks,
>> then this is be a fine place for that discussion.
>>
>> Regards,
>> S.
>>
>> PS:
>>
>> On 02/11/10 08:35, Keiichi SHIMA wrote:
>>> Dear all,
>>>
>>> My apologies if I am sending an inappropriate message.
>>>
>>> We are recently considering a mechanism for vehicles to communicate each other in a distributed manner based on the DTN concept for (real) traffic probing systems.  We looked for proper WGs in IETF, but it seems there is none.  So we decided to contact the DTNRG first.  If you think we should move to somewhere more appropriate, then please let us know the place.
>>>
>>>
>>> Below are the I-Ds we are currently working on.  Since we missed the cut off date, these I-Ds are not available from the IETF site yet.  We will submit them once the tools site re-opens.  If you are interested in these documents, please contact us.
>>>
>>> The Message Format for Decentralized Probe Applications for Vehicles
>>> http://member.wide.ad.jp/~shima/publications/draft-uehara-dtnrg-decentralized-probe-message.txt
>>>
>>> The Transport Protocol for Decentralized Probe Applications for Vehicles
>>> http://member.wide.ad.jp/~shima/publications/draft-uehara-dtnrg-decentralized-probe-message.txt
>>>
>>> Best Regards,
>>> ---
>>> Keiichi SHIMA
>>> Research Laboratory, IIJ Innovation Institute  <[email-masked]>
>>> WIDE Project <[email-masked]>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> dtn-interest mailing list
>>> [email-masked]
>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>>
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

From: Keiichi SHIMA <[email-masked]>
Date: Tue, 2 Nov 2010 19:45:44 +0900
To: Stephen Farrell <[email-masked]>
Cc: IMAIKE Masayoshi <[email-masked]>, UEHARA Keisuke <[email-masked]>, [email-masked], SATO Masaaki <[email-masked]>
Subject: Re: [dtn-interest] Inter-vehicle probe system using DTN concept

Hello Stephen Farrell,

Thank you for your quick response.

On Nov 2, 2010, at 6:14 PM, Stephen Farrell wrote:

> From a quick look at your drafts however, its not clear
> to me that there's that much in common between your current
> solution and the type of store-and-forward network that
> is typically discussed here. Can you elaborate on why
> your drafts (but mostly the transport one) specify a
> protocol that is delay or disruption tolerant, and why,
> e.g. you didn't feel it would be useful to use the BP?

I understand your question.  The reason why we wrote these drafts is that we had to work on this task to make a prototype system in very short term.  And, by chance, we had a similar system we were using before.  We thought that it would be better to disclose the concept of this distributed probe application and start discussion on it before adapting our message exchange mechanism to standardized ways.

It would have taken some more time if we started modifying the protocols before proposing the idea, because to do that, we need to investigate the existing standard protocols specified in this RG in detail if they can be replacements of our transport mechanisms.

> In other words, why is a new delay-tolerant protocol
> needed here, and is the protocol you've specified
> actually delay-tolerant?

So, my position is I am open to adapt our transport mechanisms to any standard DTN protocols as long as the application works.  (For the second question, it is hard for us to answer it... we need experts and that is another reason why we contacted this RG.)

> My guess is that if for some reason you needed to
> use exactly the bits-on-the-wire from your current
> I-Ds, then DTNRG would probably not turn out to be a
> productive place for discussions.

I fully understand.  As I said, if this topic is acceptable in this RG, then we are OK to modify our specially crafted protocols to more standardized ones.  It is not our intention to insist on the current protocols.

> However, if what you're interested in is figuring out
> how DTN mechanisms might work in vehicular networks,
> then this is be a fine place for that discussion.

Yes, this is a big interest of us too.

Best Regards,
---
Keiichi SHIMA
Research Laboratory, IIJ Innovation Institute  <[email-masked]>
WIDE Project <[email-masked]>

On Nov 2, 2010, at 6:14 PM, Stephen Farrell wrote:

> 
> Hi,
> 
> Discussion on DTN and vehicular networks is clearly in
> scope for DTNRG, so no problem there.
> 
> From a quick look at your drafts however, its not clear
> to me that there's that much in common between your current
> solution and the type of store-and-forward network that
> is typically discussed here. Can you elaborate on why
> your drafts (but mostly the transport one) specify a
> protocol that is delay or disruption tolerant, and why,
> e.g. you didn't feel it would be useful to use the BP?
> In other words, why is a new delay-tolerant protocol
> needed here, and is the protocol you've specified
> actually delay-tolerant?
> 
> My guess is that if for some reason you needed to
> use exactly the bits-on-the-wire from your current
> I-Ds, then DTNRG would probably not turn out to be a
> productive place for discussions.
> 
> However, if what you're interested in is figuring out
> how DTN mechanisms might work in vehicular networks,
> then this is be a fine place for that discussion.
> 
> Regards,
> S.
> 
> PS:
> 
> On 02/11/10 08:35, Keiichi SHIMA wrote:
>> Dear all,
>> 
>> My apologies if I am sending an inappropriate message.
>> 
>> We are recently considering a mechanism for vehicles to communicate each other in a distributed manner based on the DTN concept for (real) traffic probing systems.  We looked for proper WGs in IETF, but it seems there is none.  So we decided to contact the DTNRG first.  If you think we should move to somewhere more appropriate, then please let us know the place.
>> 
>> 
>> Below are the I-Ds we are currently working on.  Since we missed the cut off date, these I-Ds are not available from the IETF site yet.  We will submit them once the tools site re-opens.  If you are interested in these documents, please contact us.
>> 
>> The Message Format for Decentralized Probe Applications for Vehicles
>> http://member.wide.ad.jp/~shima/publications/draft-uehara-dtnrg-decentralized-probe-message.txt
>> 
>> The Transport Protocol for Decentralized Probe Applications for Vehicles
>> http://member.wide.ad.jp/~shima/publications/draft-uehara-dtnrg-decentralized-probe-message.txt
>> 
>> Best Regards,
>> ---
>> Keiichi SHIMA
>> Research Laboratory, IIJ Innovation Institute  <[email-masked]>
>> WIDE Project <[email-masked]>
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>> 

Date: Tue, 02 Nov 2010 09:14:22 +0000
From: Stephen Farrell <[email-masked]>
To: Keiichi SHIMA <[email-masked]>
Cc: UEHARA Keisuke <[email-masked]>, IMAIKE Masayoshi <[email-masked]>, [email-masked], SATO Masaaki <[email-masked]>
Subject: Re: [dtn-interest] Inter-vehicle probe system using DTN concept

Hi,

Discussion on DTN and vehicular networks is clearly in
scope for DTNRG, so no problem there.

>From a quick look at your drafts however, its not clear
to me that there's that much in common between your current
solution and the type of store-and-forward network that
is typically discussed here. Can you elaborate on why
your drafts (but mostly the transport one) specify a
protocol that is delay or disruption tolerant, and why,
e.g. you didn't feel it would be useful to use the BP?
In other words, why is a new delay-tolerant protocol
needed here, and is the protocol you've specified
actually delay-tolerant?

My guess is that if for some reason you needed to
use exactly the bits-on-the-wire from your current
I-Ds, then DTNRG would probably not turn out to be a
productive place for discussions.

However, if what you're interested in is figuring out
how DTN mechanisms might work in vehicular networks,
then this is be a fine place for that discussion.

Regards,
S.

PS:

On 02/11/10 08:35, Keiichi SHIMA wrote:
> Dear all,
> 
> My apologies if I am sending an inappropriate message.
> 
> We are recently considering a mechanism for vehicles to communicate each other in a distributed manner based on the DTN concept for (real) traffic probing systems.  We looked for proper WGs in IETF, but it seems there is none.  So we decided to contact the DTNRG first.  If you think we should move to somewhere more appropriate, then please let us know the place.
> 
> 
> Below are the I-Ds we are currently working on.  Since we missed the cut off date, these I-Ds are not available from the IETF site yet.  We will submit them once the tools site re-opens.  If you are interested in these documents, please contact us.
> 
> The Message Format for Decentralized Probe Applications for Vehicles
> http://member.wide.ad.jp/~shima/publications/draft-uehara-dtnrg-decentralized-probe-message.txt
> 
> The Transport Protocol for Decentralized Probe Applications for Vehicles
> http://member.wide.ad.jp/~shima/publications/draft-uehara-dtnrg-decentralized-probe-message.txt
> 
> Best Regards,
> ---
> Keiichi SHIMA
> Research Laboratory, IIJ Innovation Institute  <[email-masked]>
> WIDE Project <[email-masked]>
> 
> 
> 
> 
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

From: Keiichi SHIMA <[email-masked]>
Date: Tue, 2 Nov 2010 17:39:31 +0900
To: [email-masked]
Cc: IMAIKE Masayoshi <[email-masked]>, UEHARA Keisuke <[email-masked]>, SATO Masaaki <[email-masked]>
Subject: Re: [dtn-interest] Inter-vehicle probe system using DTN concept

Sorry, one of the links was incorrect.

> The Transport Protocol for Decentralized Probe Applications for Vehicles
> http://member.wide.ad.jp/~shima/publications/draft-uehara-dtnrg-decentralized-probe-message.txt

should be http://member.wide.ad.jp/~shima/publications/draft-uehara-dtnrg-decentralized-probe-transport.txt

---
Keiichi SHIMA
Research Laboratory, IIJ Innovation Institute  <[email-masked]>
WIDE Project <[email-masked]>

On Nov 2, 2010, at 5:35 PM, Keiichi SHIMA wrote:

> Dear all,
> 
> My apologies if I am sending an inappropriate message.
> 
> We are recently considering a mechanism for vehicles to communicate each other in a distributed manner based on the DTN concept for (real) traffic probing systems.  We looked for proper WGs in IETF, but it seems there is none.  So we decided to contact the DTNRG first.  If you think we should move to somewhere more appropriate, then please let us know the place.
> 
> 
> Below are the I-Ds we are currently working on.  Since we missed the cut off date, these I-Ds are not available from the IETF site yet.  We will submit them once the tools site re-opens.  If you are interested in these documents, please contact us.
> 
> The Message Format for Decentralized Probe Applications for Vehicles
> http://member.wide.ad.jp/~shima/publications/draft-uehara-dtnrg-decentralized-probe-message.txt
> 
> The Transport Protocol for Decentralized Probe Applications for Vehicles
> http://member.wide.ad.jp/~shima/publications/draft-uehara-dtnrg-decentralized-probe-message.txt
> 
> Best Regards,
> ---
> Keiichi SHIMA
> Research Laboratory, IIJ Innovation Institute  <[email-masked]>
> WIDE Project <[email-masked]>
> 
> 
> 
> 
> 
> 

From: Keiichi SHIMA <[email-masked]>
Date: Tue, 2 Nov 2010 17:35:43 +0900
To: [email-masked]
Cc: UEHARA Keisuke <[email-masked]>, IMAIKE Masayoshi <[email-masked]>, SATO Masaaki <[email-masked]>
Subject: [dtn-interest] Inter-vehicle probe system using DTN concept

Dear all,

My apologies if I am sending an inappropriate message.

We are recently considering a mechanism for vehicles to communicate each other in a distributed manner based on the DTN concept for (real) traffic probing systems.  We looked for proper WGs in IETF, but it seems there is none.  So we decided to contact the DTNRG first.  If you think we should move to somewhere more appropriate, then please let us know the place.

Below are the I-Ds we are currently working on.  Since we missed the cut off date, these I-Ds are not available from the IETF site yet.  We will submit them once the tools site re-opens.  If you are interested in these documents, please contact us.

The Message Format for Decentralized Probe Applications for Vehicles
http://member.wide.ad.jp/~shima/publications/draft-uehara-dtnrg-decentralized-probe-message.txt

The Transport Protocol for Decentralized Probe Applications for Vehicles
http://member.wide.ad.jp/~shima/publications/draft-uehara-dtnrg-decentralized-probe-message.txt

Best Regards,
---
Keiichi SHIMA
Research Laboratory, IIJ Innovation Institute  <[email-masked]>
WIDE Project <[email-masked]>

From: "Golding, Len" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Mon, 1 Nov 2010 09:04:11 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] unsubscribe

--_000_E48B962F2B71EC4C97EF42A839D0F2DE0570A9A169IMCMBX1MITREO_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Please remove me from this mailing list

--_000_E48B962F2B71EC4C97EF42A839D0F2DE0570A9A169IMCMBX1MITREO_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DWordSection1>

<p class=3DMsoNormal>Please remove me from this mailing list<o:p></o:p></p>

</div>

</body>

</html>

--_000_E48B962F2B71EC4C97EF42A839D0F2DE0570A9A169IMCMBX1MITREO_--