Massimiliano Laddomada | 2 Mar 2008 17:04
Picon
Favicon

[Mycolleagues] CFP-Iterative Decoding and Cross-Layering Techniques for Multimedia Broadcasting and Communications

%%% Please accept our apologies if you receive multiple 
copies of this announcement %%%%

Hindawi - International Journal of Digital Multimedia 
Broadcasting

http://www.hindawi.com/journals/ijdmb/

Call for Papers
Iterative Decoding and Cross-Layering Techniques for 
Multimedia Broadcasting and Communications

The explosive growth of multimedia applications over the 
Internet and the ever-increasing users' demands over 
commercial terrestrial digital multimedia broadcasting all 
over the world call for efficient physical and cross-layer 
techniques able to mitigate the potential problems 
limiting broadband services over wireless networks. In 
this scenario, mobile multimedia is expected to be one of 
the key services of future wireless mobile networks. 
Meanwhile, recent advances in digital communications have 
paved the way to a variety of standards aimed at providing 
multimedia services over terrestrial broadband networks. 
To cite but a few, DVB-H, T-DVB, T-DMB, wireless LANs, and 
wireless MANs are some of the most recent standards 
enabling such technology.

Iterative decoding techniques for both source, channel, 
and joint source-channel coding and decoding and 
cross-layering techniques have proven to be very effective 
(Continue reading)

Vincent Roca | 9 Mar 2008 15:06
Picon

Status of the TESLA for ALC/NORM I-D

Hello,

As promised, here are a few comments about the status of the
new TESLA for ALC/NORM I-D.

The new document:
http://www.ietf.org/internet-drafts/draft-ietf-msec-tesla-for-alc-norm-04.txt

...and the diff with -03:
http://tools.ietf.org/rfcdiff?url2=http://tools.ietf.org/id/draft-ietf-msec-tesla-for-alc-norm-04.txt

Regards,

   Vincent et al.

General comments:
-----------------

The document is now considered as stable.

The whole specification turns out to be relatively complex,
essentially because:

1- it defines a working mode that is self-sufficient, instead of
    relying on several external documents to address for instance
    the bootstraping aspects.
    Of course this does not mean that all use-cases must follow
    the built-in bootstrap mode: it remains an optional feature.

2- it defines 8(!) different authentication tags.
(Continue reading)

Mieso Denko | 7 Mar 2008 16:34
Picon

[Mycolleagues] Deadline extended until March 10, 2008: International Symposium on Pervasive Grid (PerGrid 2008)

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

-----------------------------------------------------------------------------
           CALL  FOR PAPERS

     International Symposium on Pervasive Grid (PerGrid-08)

     In conjunction with 2008 IEEE 11th International
     Conference on Computational Science and Engineering, July
     16-18, 2008 - Sao Paulo - Brazil

     http://nets-www.lboro.ac.uk/lin/PGrid08/

-----------------------------------------------------------------------------


We invite you to participate in the International
Symposium on Pervasive Grid (PerGrid-08), to be held in Sao
Paulo, Brazil on the 16th-18th July 2008. This Symposium
brings the integration of two important subjects of
nowadays researches (Grid and Pervasive Computing) which
originated the Pervasive Grid.

Pervasive Grid stands for hardware and software
infrastructures or space/environment that provides
proactive, autonomic, trustworthy, and inexpensive access
to pervasive resource sharing capabilities anywhere,
anytime, anyhow. Such resources can be either high
performance clusters or smart devices such as sensors,
appliances, robots etc. This symposium intends to serve as
the forum for the latest advances in Pervasive Grid
research.

This symposium seeks topics among the following challenges
in Pervasive Grid (but not limited to):

- Power management
- Real-time embedded systems
- Sensor networks
- Universal ID
- Devices miniaturization
- Ubiquitous/pervasive networks
- Ad hoc mobility
- Open service architecture
- Sensed information overload & database
- Context semantics & management
- Autonomic system administration
- User interfaces
- Operating systems
- Languages
- Middlewares
- Integration
- Cooperation
- Scalability
- Heterogeneity
- Dependability
- Availability
- Security and privacy
- Test
- Evaluation
- Standards

Paper Submission
----------------
Submit your paper by http://cse.stfx.ca/~cse08workshops/sub/.
Authors are expected to submit a paper in PDF format with
5-10 keywords following the IEEE CS format. Program
committee members and external reviewers will provide
authors with independent reviews. Submitted papers will be
ranked based on relevance to the Conference and technical
merit. Final version of accepted papers should be at most 6
pages and will be published by IEEE Computer Society Press
with the CSE-08 workshop proceedings. Authors of accepted
papers, or at least one of them, are requested to register
and present their work at the conference, otherwise their
papers will be removed from the IEEE Digital Library after
the conference.

Important Dates
---------------
Paper submission due:  March 10, 2008 (extended)
Paper notification of acceptance: April 01, 2008
Final camera ready: April 25, 2008

Special Issue
-------------
Selected high quality papers will be invited for possible publication in
the Special Issue of the International Journal of  Multimedia and
Ubiquitous Engineering after further extension.

Organizing Committee
--------------------
Steering Chair: Laurence Tianruo Yang, St. Fracis Xavier University,
Canada


General Co-Chairs
-----------------
Rodrigo Fernandes de Mello, University of So Paulo, ICMC, Brazil
Mieso Denko, University of Guelph, Canada
Xingang Wang (University of Plymouth, United Kingdom)


Program Co-Chairs
-----------------
Jean-Marc Pierson (Universit Paul Sabatier, France)
Lin Guan (University of Loughborough, United Kingdom)
Dongwon Jeong (Kunsan National University, Korea)




_______________________________________________
Mycolleagues mailing list
Mycolleagues <at> grid.lrg.ufsc.br
http://grid.lrg.ufsc.br/mailman/listinfo/mycolleagues
_______________________________________________
Rmt mailing list
Rmt <at> ietf.org
https://www.ietf.org/mailman/listinfo/rmt
Zhang, Liqiang | 6 Mar 2008 17:02

[Mycolleagues] CFP: ACM TAAS Special Issue on Self-Adaptive and Self-Organizing Wireless Networking Systems

Apologies if you receive multiple copies

 

----------------------------------------------------------------------------------------

                         CALL FOR PAPERS

           ACM Transactions on Autonomous and Adaptive Systems

                         Special Issue on

       Self-Adaptive and Self-Organizing Wireless Networking Systems 

 

 

                  http://taas.acm.org/TAAS-ACM-SelfOrg-WSN.pdf

 

****************************************************************************************

Recent advances in wireless communications and networking, distributed sensing and

control, and real-time and embedded systems have led to some new computing paradigms,

such as ubiquitous and pervasive computing, wireless sensor networks, and cyber-physical

systems. Many novel and attractive applications are made possible, such as advanced

automotive systems, environmental control, critical infrastructure control, high

confidence medical devices and systems, etc. In these applications, a large scale wireless

networking system that consists of massive numbers of connected processing elements,

sensors, and actuators often plays a key role.  The high complexity of such large scale

heterogeneous systems raises new challenges to the system design:  we expect the system

to be context-aware and self-adaptive to internal and external environments to achieve

reliable and robust performance; to be self-organizing and scalable so that managing and

maintaining costs could be minimized; to have programmable architecture and protocols for

achieving optimal performance in different situations/scenarios, etc. These challenges

need to be addressed under joint efforts from different areas, such as networking, system,

control, AI, biology, and others. 

 

The special issue seeks original and unpublished papers that address theoretical and

experimental work related to self-adaptive and self-organizing wireless networking systems

(SASOWNS). Papers are solicited from, but are not limited to, the following topics:

 

 

•    Self-adaptive architectures, algorithms, and protocols

•    Control theoretical approaches for self-optimization

•    Self-organizing wireless mesh, ad hoc, and sensor networking

•    Self-configurable and programmable MAC and routing protocols

•    Biological, economic, and social models for large scale SASOWNS

•    Applications and testbeds of SASOWNS

•    Autonomic and autonomous wireless networking systems

 

 

IMPORTANT DATES

---------------

 

Paper submission due:   July 31st, 2008

Acceptance notification: Dec. 31st, 2008

Camera-ready due:  Feb. 28th, 2009

Tentative publication date: June/Sep. 2009

 

 

SUBMISSION FORMAT AND REVIEW GUIDELINES

---------------------------------------

 

Authors are invited to submit manuscripts reporting important developments (or advances) in

the topics related to the special issue. The submitted papers must be written in English and

describe original research not published nor currently under review by other journals or

conferences. Parallel submissions will not be accepted. If an earlier version of the manuscript

was published/accepted in conferences, authors should state so in the cover letter. 

The manuscript must be a substantial extension to the previously published/accepted work and

a summary of changes and a copy of the previous conference paper must be submitted together

with the submission to the special issue.

 

Guest editors will pre-screen submitted manuscripts for their suitability in the issue.

Submissions passing the pre-screen process will go through a rigorous peer-review process

according to the standards of TAAS. Submitting a paper implies the willingness of reviewing

one paper submitted to the special issue. 

 

 

SUBMISSION GUIDELINES

---------------------

 

The manuscripts should be formatted according to the ACM TAAS guidelines available from the

journal homepage (http://www.acm.org/pubs/taas) and submitted to the guest editors through

email (cpoellab <at> cse.nd.edu).

 

 

GUEST EDITORS

-------------

 

Dr. Michael Lemmon

Dept. of Electrical Engineering

University of Notre Dame

Notre Dame, IN 46556

Email: lemmon <at> nd.edu

Http: www.nd.edu/~lemmon

 

Dr. Christian Poellabauer

Dept. of Computer Science and Engineering

University of Notre Dame

Notre Dame, IN 46556

Email: cpoellab <at> cse.nd.edu

Http: www.cse.nd.edu/~cpoellab

 

Dr. Liqiang Zhang

Dept. of Computer and Information Sciences

Indiana University South Bend

South Bend, IN 46615

Email: liqzhang <at> cs.iusb.edu

 Http: www.cs.iusb.edu/~liqzhang  

 

Dr. Xiaobo Zhou

Dept. of Computer Science

University of Colorado at Colorado Springs

Colorado Springs, CO 80918

Email: zbo <at> cs.uccs.edu

Http: www.cs.uccs.edu/~zbo

 

 

****************************************************************************************

 

_______________________________________________
Mycolleagues mailing list
Mycolleagues <at> grid.lrg.ufsc.br
http://grid.lrg.ufsc.br/mailman/listinfo/mycolleagues
_______________________________________________
Rmt mailing list
Rmt <at> ietf.org
https://www.ietf.org/mailman/listinfo/rmt
Vincent Roca | 9 Mar 2008 16:08
Picon

Comments on WGLC for draft-rmt-bb-lct-revised-06

Mark and al.

I went through the whole document and here are a few comments:

Potentially controversial comments:

1- the version number of this specification is set to 1, i.e.,
   the same value as that of RFC3451 whereas many features have
   changed. I can understand that a specification that makes
   obsolete the previous specification keep the same version
   value. Yet it must be considered that in the meantime LCT has
   been widely deployed, and from this point of view I'm a little
   bit concerned by this choice. I don't remember any previous
   discussion on this topic.

2- the CCI (Congestion Control Information) field length is still
   set to:   length = 32*(C+1) bits
   In other words it mandate that each LCT packet contain at least
   a 32 bit CCI field.
   Though I agree on the fact that CC is mandatory, I'm wondering
   if it wouldn't be wiser not to mandate the presence of the CCI
   field in all LCT packets. It is straightforward, we just need
   to say that length = 32*C.
   The motivation: with some CC mechanisms, in particular in case
   of a CBR (constant bit rate) transmission within a CBR channel,
   the CCI field is not used and zero'd. That's the case AFAIK
   in all DVB-* use-cases.
   If we change as suggested, the fact that it is no longer
   possible to have CCI fields that are 128 bit long is not a big
   issue since long CCI fields can be moved to a specific HE.

Minor comments:

3- p.17, Close Session flag: It is said:
       A received packet with A set to 1 indicates to a
       receiver that the sender will immediately stop sending packets for
       the session.
    Instead of "immediately", I'd rather say "imminently" since
    there can be several such packets as it is explained.

    p.17, Close Object flag: same remark

4- 5.2.1.  General: It is said:
   o  Sender and Receiver authentication information.
    The use of HE for "receiver authentication" contradicts
    what is said before (e.g., in section 2. Rationale) that
    LCT is purely unidirectional.
    I suggest to remove any reference to "receiver" here, even
    if the same HE format could be used in another context.

5- 5.2.1, p.22: it is said:
       If EXT_AUTH is present,
       whatever packet authentication checks that can be
       performed immediately upon reception of the packet
       SHOULD be performed before accepting the packet and
       performing any congestion control-related action on it.
    Is the SHOULD appropriate here? I'd rather say MUST.

6- p.25: it is said, concerning the PI-specific use field:
       The bits that
       are not specified by the PI built on top of LCT SHOULD
       be set to zero.
    Is the SHOULD appropriate here? I'd rather say MUST,
    even if it refers to another document.

7- p.28, section 6.1:
    I suggest that instead of MTU, the text refers to PMTU
    (Path MTU) which is the key requirement to improve end-2-end
    transmissions efficient.
    The words "or when" in this sentence is also probably an
    error. I guess the authors mean "otherwise".

8- Section 8. This security section can probably be improved.
    In particular (but not only) appending an MD5 hash to the
    object without any signature cannot be regarded as offering
    any security since any wise attacker will change the hash
    in such a way to make the attack invisible.

A few typos:

* p.22: singe -> single in:
    applicability (for example to a singe Protocol Instantiation) SHOULD

* p.27: is -> are in:
    distribution of session descriptions is beyond the scope of this

* p.31, bottom: the right reference is probably [RIZ1997b].
   Anyway [RIZ1997] and [RIZ1997a] are a duplicated single reference.

* p.35, 9.1: Instanciation is badly spelled.
   Besides, is it appropriate to refer to the "previous Experimental
   version of this specification"?
   I believe that RFC3451 is more appropriate.

* p.35, 9.2: two -> three
    This document registers two values in the namespace "ietf:rmt:lct:

And a final suggestion:

* in sections 2 and 4, on several occasions it is said:
   "the use of coding for reliability".
   I understand it, but shouldn' we say instead: "the use of
   FEC encoding for reliability"? I think it clarifies what is
   meant by "coding".
Brian Adamson | 9 Mar 2008 23:04
Picon
Picon

IETF71 RMT Presentations for Upload

If any of the presenters can provide a preview of slides for the RMT 
WG meeting, I can upload them before the meeting.

Additionally, there is a little bit of open time on the agenda for 
any last minute agenda requests.

best regards,

--

-- 
Brian
__________________________________
Brian Adamson
<http://cs.itd.nrl.navy.mil/5522>
<mailto:adamson <at> itd.nrl.navy.mil>
Vincent Roca | 10 Mar 2008 19:53
Picon

Re: Comments on WGLC for draft-rmt-bb-lct-revised-06

Mark,

Thanks for the clarification.
I agree that if we don't want to implement (2) in order to
maintain backward compatibility, then there's no need to
update the version number. Since the answer is not so trivial,
I suggest to add a note somewhere in the document.

Cheers,

   Vincent

Mark Watson a écrit :
> Vincent, all,
> 
> It looks like I was mistaken in the meeting - 3GPP, at least, references
> RFC3451 (the Experimental RFC).
> 
> However, in the changes that we made to LCT, we did go to some trouble to
> maintain backwards compatibility:
> - The removal of the SCT and ERT from the header was accompanied by a
> requirement to set the indicator bits for these headers to zero, so that old
> receivers will not expect the fields themselves to be present
> - The new Protocol Specific Information (PSI) field replaces bits that were
> reserved in RFC3451 and 3451 specifically requires receivers to ignore them
> 
> A new protocol version number is only required when
> backwards-incompatibility is introduced and we have taken care not to do
> that here. So I still think the changes (1) and (2) below are unnecessary.
> 
> Regards,
> 
> Mark
> 
> 
> On 3/9/08 7:08 AM, "Vincent Roca" <vincent.roca <at> inrialpes.fr> wrote:
> 
>> Mark and al.
>>
>> I went through the whole document and here are a few comments:
>>
>> Potentially controversial comments:
>>
>> 1- the version number of this specification is set to 1, i.e.,
>>    the same value as that of RFC3451 whereas many features have
>>    changed. I can understand that a specification that makes
>>    obsolete the previous specification keep the same version
>>    value. Yet it must be considered that in the meantime LCT has
>>    been widely deployed, and from this point of view I'm a little
>>    bit concerned by this choice. I don't remember any previous
>>    discussion on this topic.
>>
>> 2- the CCI (Congestion Control Information) field length is still
>>    set to:   length = 32*(C+1) bits
>>    In other words it mandate that each LCT packet contain at least
>>    a 32 bit CCI field.
>>    Though I agree on the fact that CC is mandatory, I'm wondering
>>    if it wouldn't be wiser not to mandate the presence of the CCI
>>    field in all LCT packets. It is straightforward, we just need
>>    to say that length = 32*C.
>>    The motivation: with some CC mechanisms, in particular in case
>>    of a CBR (constant bit rate) transmission within a CBR channel,
>>    the CCI field is not used and zero'd. That's the case AFAIK
>>    in all DVB-* use-cases.
>>    If we change as suggested, the fact that it is no longer
>>    possible to have CCI fields that are 128 bit long is not a big
>>    issue since long CCI fields can be moved to a specific HE.
>>
>>
>> Minor comments:
>>
>> 3- p.17, Close Session flag: It is said:
>>        A received packet with A set to 1 indicates to a
>>        receiver that the sender will immediately stop sending packets for
>>        the session.
>>     Instead of "immediately", I'd rather say "imminently" since
>>     there can be several such packets as it is explained.
>>
>>     p.17, Close Object flag: same remark
>>
>> 4- 5.2.1.  General: It is said:
>>    o  Sender and Receiver authentication information.
>>     The use of HE for "receiver authentication" contradicts
>>     what is said before (e.g., in section 2. Rationale) that
>>     LCT is purely unidirectional.
>>     I suggest to remove any reference to "receiver" here, even
>>     if the same HE format could be used in another context.
>>
>>
>> 5- 5.2.1, p.22: it is said:
>>        If EXT_AUTH is present,
>>        whatever packet authentication checks that can be
>>        performed immediately upon reception of the packet
>>        SHOULD be performed before accepting the packet and
>>        performing any congestion control-related action on it.
>>     Is the SHOULD appropriate here? I'd rather say MUST.
>>
>> 6- p.25: it is said, concerning the PI-specific use field:
>>        The bits that
>>        are not specified by the PI built on top of LCT SHOULD
>>        be set to zero.
>>     Is the SHOULD appropriate here? I'd rather say MUST,
>>     even if it refers to another document.
>>
>> 7- p.28, section 6.1:
>>     I suggest that instead of MTU, the text refers to PMTU
>>     (Path MTU) which is the key requirement to improve end-2-end
>>     transmissions efficient.
>>     The words "or when" in this sentence is also probably an
>>     error. I guess the authors mean "otherwise".
>>
>> 8- Section 8. This security section can probably be improved.
>>     In particular (but not only) appending an MD5 hash to the
>>     object without any signature cannot be regarded as offering
>>     any security since any wise attacker will change the hash
>>     in such a way to make the attack invisible.
>>
>>
>> A few typos:
>>
>> * p.22: singe -> single in:
>>     applicability (for example to a singe Protocol Instantiation) SHOULD
>>
>> * p.27: is -> are in:
>>     distribution of session descriptions is beyond the scope of this
>>
>> * p.31, bottom: the right reference is probably [RIZ1997b].
>>    Anyway [RIZ1997] and [RIZ1997a] are a duplicated single reference.
>>
>> * p.35, 9.1: Instanciation is badly spelled.
>>    Besides, is it appropriate to refer to the "previous Experimental
>>    version of this specification"?
>>    I believe that RFC3451 is more appropriate.
>>
>> * p.35, 9.2: two -> three
>>     This document registers two values in the namespace "ietf:rmt:lct:
>>
>>
>> And a final suggestion:
>>
>> * in sections 2 and 4, on several occasions it is said:
>>    "the use of coding for reliability".
>>    I understand it, but shouldn' we say instead: "the use of
>>    FEC encoding for reliability"? I think it clarifies what is
>>    meant by "coding".
>>
>> _______________________________________________
>> Rmt mailing list
>> Rmt <at> ietf.org
>> https://www.ietf.org/mailman/listinfo/rmt
>>
> 
> 
> 

--

-- 
------------------------------ http://planete.inrialpes.fr/people/roca/
   INRIA Rhone-Alpes - planete research team   vincent.roca <at> inria.fr
   Inovallée; 655 av de l'Europe; Montbonnot   phone (+33) 4.76.61.52.16
   38334 ST ISMIER cedex - France              fax   (+33) 4.76.61.52.52
Magnus Westerlund | 19 Mar 2008 15:45
Picon
Favicon

AD comments on draft-ietf-rmt-bb-norm-revised-03

Hi,

I did my AD review of the draft and have only one real comment:

I think the security section is not particular well describing the 
security issues. Especially with bad guys that are authenticated but 
still are badly behaving. I think expanding it somewhat and try to 
separate the potential solutions from the problems. And also address 
when the solutions are only partial solutions.

Nits:
Section 1: I think you should break the paragraph with RFC 2119 language 
at the end into two.

Statement of intention, first paragraph: There is a stray space before 
the "." in the second sentence.

On many places the document uses "_"word to be underlined"_" construct. 
They are not approved embellishments to use in RFCs, so please change them.

I am expecting an updated draft.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund <at> ericsson.com
----------------------------------------------------------------------
Brian Adamson | 19 Mar 2008 16:08
Picon
Picon

Re: AD comments on draft-ietf-rmt-bb-norm-revised-03

Thanks Magnus,

I will provide an updated draft ASAP.

At 3:45 PM +0100 3/19/08, Magnus Westerlund wrote:
>Hi,
>
>I did my AD review of the draft and have only one real comment:
>
>I think the security section is not particular well describing the 
>security issues. Especially with bad guys that are authenticated but 
>still are badly behaving. I think expanding it somewhat and try to 
>separate the potential solutions from the problems. And also address 
>when the solutions are only partial solutions.
>
>
>
>Nits:
>Section 1: I think you should break the paragraph with RFC 2119 
>language at the end into two.
>
>Statement of intention, first paragraph: There is a stray space 
>before the "." in the second sentence.
>
>On many places the document uses "_"word to be underlined"_" 
>construct. They are not approved embellishments to use in RFCs, so 
>please change them.
>
>I am expecting an updated draft.
>
>Cheers
>
>Magnus Westerlund
>
>IETF Transport Area Director & TSVWG Chair
>----------------------------------------------------------------------
>Multimedia Technologies, Ericsson Research EAB/TVM
>----------------------------------------------------------------------
>Ericsson AB                | Phone +46 8 4048287
>Torshamsgatan 23           | Fax   +46 8 7575550
>S-164 80 Stockholm, Sweden | mailto: magnus.westerlund <at> ericsson.com
>----------------------------------------------------------------------

--

-- 
Brian
__________________________________
Brian Adamson
<mailto:adamson <at> itd.nrl.navy.mil>

Gmane