Internet-Drafts | 2 Jul 00:15 2010
Picon

I-D Action:draft-ietf-rmt-fcast-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.

	Title           : FCAST: Scalable Object Delivery for the ALC and NORM Protocols
	Author(s)       : V. Roca, B. Adamson
	Filename        : draft-ietf-rmt-fcast-01.txt
	Pages           : 31
	Date            : 2010-07-01

This document introduces the FCAST object (e.g., file) delivery
application on top of the ALC and NORM reliable multicast protocols.
FCAST is a highly scalable application that provides a reliable
object delivery service.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-fcast-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Attachment (draft-ietf-rmt-fcast-01.txt): message/external-body, 70 bytes
_______________________________________________
Rmt mailing list
Rmt <at> ietf.org
https://www.ietf.org/mailman/listinfo/rmt
(Continue reading)

Internet-Drafts | 2 Jul 00:45 2010
Picon

I-D Action:draft-ietf-rmt-simple-auth-for-alc-norm-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.

	Title           : Simple Authentication Schemes for the ALC and NORM Protocols
	Author(s)       : V. Roca
	Filename        : draft-ietf-rmt-simple-auth-for-alc-norm-03.txt
	Pages           : 29
	Date            : 2010-07-01

This document introduces four schemes that provide a per-packet
authentication and integrity service in the context of the ALC and
NORM protocols.  The first scheme is based on digital signatures.
Because it relies on asymmetric cryptography, this scheme generates a
high processing load at the sender and to a lesser extent at a
receiver, as well as a significant transmission overhead.  It is
therefore well suited to low data rate sessions.  The second scheme
relies on the Elliptic Curve Digital Signature Algorithm (ECDSA).  If
this approach also relies an asymmetric cryptography, the processing
load and the transmission overhead are significantly reduced compared
to traditional digital signature schemes.  It is therefore well
suited to medium data rate sessions.  The third scheme relies on a
group Message Authentication Code (MAC).  Because this scheme relies
on symmetric cryptography, MAC calculation and verification are fast
operations, which makes it suited to high data rate sessions.
However it only provides a group authentication and integrity
service, which means that it only protects against attackers that are
not group members.  Finally, the fourth scheme merges the digital
signature and group group schemes, and is useful to mitigate DoS
attacks coming from attackers that are not group members.

(Continue reading)

Jani Peltotalo | 2 Jul 09:57 2010
Picon
Picon

Re: FLUTE SDP specification - update status check

Hi all again,

06 version of the FLUTE SDP is now available:

http://tools.ietf.org/html/draft-mehta-rmt-flute-sdp-06

We will continue updating work after summer holidays, so all comments to
the open questions and to the specification itself are very welcome.

Cheers, Jani & Rod

> Hi All
> 
> Status of this doc is:
> 
>  - typos and clarifications are dealt with
>  - cross-referencing and updating of all references is done
>  - the 5 questions we asked to RMT remain open
>  - CC and sec are under investigation (haven't checked 
> draft-saito-mmusic-sdp-ike-07 yet)
>  - MMUSIC warm-up email sent, and a couple of issues quizzed
>  - probable will upload an 06 "snapshot" this week, and follow with an 
> 07 "all ready" version for WGLC (maybe that'll be an 08)
> 
> Cheers, Rod & Jani
> 
Habeeb Mohiuddin Mohammed | 2 Jul 14:30 2010
Picon

Draft Message

   Dear RMT experts,

My name is Habeeb Mohiuddin Mohammed, a MSCE Student at the Munich University of Technology. In my internship project I implemented the RaptorQ encoder and decoder as specified in draft-ietf-rmt-bb-fec-raptorq-02. The draft easily enabled implementation of the algorithms and protocols. Nevertheless, during the implementation I detected some ambiguities. Therefore, I contacted the authors of the draft to clarify those, in particular the use and implementation of GF(256) operations.

It turned out that the specification was correct and only some misunderstandings from my side. However, the authors were kind enough to address the ambiguities and provide me an updated specification and also integrated the clarification in latest draft draft-ietf-rmt-bb-fec-raptorq-03.

We also agreed to exchange some test vectors for certain source block sizes that contain mixtures of source and encoding symbols. All exchanged vectors could be decoded by the other party, so we are confident to be able to claim to have two independent implementations of the RaptorQ forward error correction specification as documented in draft-ietf-rmt-bb-fec-raptorq-03.

Therefore, I support that WGLC is issued for this specification.

Regards,
Habeeb Mohiuddin Mohammed,
Graduate Student, Master in Science of Communication Eng.,
Dept. of Electrical and Information Technology,
Technische Universität München,
Arcisstraße 21, D-80290 Munich,
Germany.
Email: habeeb4016 <at> gmail.com
_______________________________________________
Rmt mailing list
Rmt <at> ietf.org
https://www.ietf.org/mailman/listinfo/rmt
Habeeb Mohiuddin Mohammed | 2 Jul 15:24 2010
Picon

Re: Announcing draft-ietf-rmt-bb-fec-raptorq-03

Dear RMT experts,

Resend of the previous e-mail with appropriate subject.

My name is Habeeb Mohiuddin Mohammed, a MSCE Student at the Munich University of Technology. In my internship project I implemented the RaptorQ encoder and decoder as specified in draft-ietf-rmt-bb-fec-raptorq-02. The draft easily enabled implementation of the algorithms and protocols. Nevertheless, during the implementation I detected some ambiguities. Therefore, I contacted the authors of the draft to clarify those, in particular the use and implementation of GF(256) operations.

It turned out that the specification was correct and only some misunderstandings from my side. However, the authors were kind enough to address the ambiguities and provide me an updated specification and also integrated the clarification in latest draft draft-ietf-rmt-bb-fec-raptorq-03.

We also agreed to exchange some test vectors for certain source block sizes that contain mixtures of source and encoding symbols. All exchanged vectors could be decoded by the other party, so we are confident to be able to claim to have two independent implementations of the RaptorQ forward error correction specification as documented in draft-ietf-rmt-bb-fec-raptorq-03.

Therefore, I support that WGLC is issued for this specification.

Best regards,

Habeeb Mohiuddin Mohammed,
Graduate Student, Master in Science of Communication Eng.,
Dept. of Electrical and Information Technology,
Technische Universität München,
Arcisstraße 21, D-80290 Munich,
Germany.
Email: habeeb4016 <at> gmail.com



On Jun 22, 2010, at 11:37 PM, Luby, Michael wrote:

RMT participants,
We have just submitted a new -03 version of “RaptorQ Forward Error Correction Scheme for Object Delivery”.   There are no basic technical changes to the actual RaptorQ code (a minor technical change is noted below).  The main change between the –02 and –03 drafts is that there was an effort to remove some of the ambiguities in the –02 draft and to make it much easier to implement (this was based on feedback from a couple of people who have implemented from the draft).  For example, we removed all the mathematical discussions of GF(256), and removed introduction of complicated mathematical operations in the middle of the draft, and isolated to Section 5.7 all symbol operations relating to GF(256), where we also describe the symbol operations solely as table lookup operations instead of trying to explain finite fields. (We do mention GF(256) in Section 5.7, but it is not necessary to understand the theory of GF(256) finite field operations to implement the draft.)  We also did some other cleanups as well, e.g., eliminated a few places where we described the same thing more than once, and maintained and cleaned up the better of multiple descriptions that provided the most straightforward way to implement.  We also isolated the requirements for a compliant decoder to a new Subsection 5.8.  We feel that these changes will help future implementers, and will also make the WGLC faster and more efficient.

The minor technical change was that we did change J(K’) values for a couple of K’ values in Table 2.  We anticipate computing and validating new J(K’) values for a few other K’ values, and these will be updated along with any WGLC comments after WGLC has been completed  (these updates have no impact on the WGLC review of the draft, as from that perspective they are just values in a table, and will be available before the WGLC is completed).   We feel that this draft is now ready for WGLC.
Regards, Mike Luby
_______________________________________________
Rmt mailing list
Rmt <at> ietf.org
https://www.ietf.org/mailman/listinfo/rmt
_______________________________________________
Rmt mailing list
Rmt <at> ietf.org
https://www.ietf.org/mailman/listinfo/rmt
Brian Adamson | 6 Jul 21:26 2010
Picon
Picon

WG Last Call: draft-ietf-rmt-bb-fec-raptorq-03

Now that the new draft (Version 03) has been published, please be advised that the revised RaptorQ FEC Scheme specification:

http://www.ietf.org/id/draft-ietf-rmt-bb-fec-raptorq-03.txt


is now officially in WG Last Call that will expire July 23, 2010.  This will allow comments to be discussed during the upcoming IETF.

Please address any comments to the document authors and this mailing list.

Thank you,
the WG chairs.




_______________________________________________
Rmt mailing list
Rmt <at> ietf.org
https://www.ietf.org/mailman/listinfo/rmt
Brian Adamson | 12 Jul 17:17 2010
Picon
Picon

IETF 78 RMT - Call for Agenda Items

Please submit any RMT Working Group agenda items by Wed, 14 July 2010.

The RMT Meeting is scheduled fo Friday, 30 July 2010 at 1300-1400.

best regards,

Brian Adamson
adamson <at> itd.nrl.navy.mil
Brian Adamson | 15 Jul 17:26 2010
Picon
Picon

IETF 78 RMT WG Draft Agenda Posted

I have posted a draft agenda for the upcoming IETF 78 RMT meeting.  It is available from:



On this agenda I have reserved discussion slots for the updated FLUTE, SDP for FLUTE, and RaptorQ documents.  I am hopeful that someone representing the document authors will be able to provide a status update on these documents.  The other documents will be covered by the WG Chairs summary.

If there are additional agenda items or volunteers to provide the update document presen tions, please let the working group chairs know as soon as possible.

best regards,

_______________________________________________
Rmt mailing list
Rmt <at> ietf.org
https://www.ietf.org/mailman/listinfo/rmt
Luby, Michael | 15 Jul 18:24 2010

Re: Rmt Digest, Vol 72, Issue 3

Perhaps a short discussion prompting wglc comments on the RaptorQ object
delivery draft?  I can provide a short presentation that perhaps Brian
Adamson can present (I won't be at this IETF meeting)?  It should take 5-10
minutes I imagine, including getting any feedback.
Mike

On 7/12/10 12:00 PM, "rmt-request <at> ietf.org" <rmt-request <at> ietf.org> wrote:

> If you have received this digest without all the individual message
> attachments you will need to update your digest options in your list
> subscription.  To do so, go to
> 
> https://www.ietf.org/mailman/listinfo/rmt
> 
> Click the 'Unsubscribe or edit options' button, log in, and set "Get
> MIME or Plain Text Digests?" to MIME.  You can set this option
> globally for all the list digests you receive at this point.
> 
> 
> 
> Send Rmt mailing list submissions to
> rmt <at> ietf.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> https://www.ietf.org/mailman/listinfo/rmt
> or, via email, send a message with subject or body 'help' to
> rmt-request <at> ietf.org
> 
> You can reach the person managing the list at
> rmt-owner <at> ietf.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Rmt digest..."
Brian Adamson | 15 Jul 21:59 2010
Picon
Picon

Re: Rmt Digest, Vol 72, Issue 3

That would be useful - I reserved a slot in the agenda for something like that.

Brian Adamson
brian.adamson <at> nrl.navy.mil

On Jul 15, 2010, at 12:24 PM, Luby, Michael wrote:

> Perhaps a short discussion prompting wglc comments on the RaptorQ object
> delivery draft?  I can provide a short presentation that perhaps Brian
> Adamson can present (I won't be at this IETF meeting)?  It should take 5-10
> minutes I imagine, including getting any feedback.
> Mike
> 
> 
> On 7/12/10 12:00 PM, "rmt-request <at> ietf.org" <rmt-request <at> ietf.org> wrote:
> 
>> If you have received this digest without all the individual message
>> attachments you will need to update your digest options in your list
>> subscription.  To do so, go to
>> 
>> https://www.ietf.org/mailman/listinfo/rmt
>> 
>> Click the 'Unsubscribe or edit options' button, log in, and set "Get
>> MIME or Plain Text Digests?" to MIME.  You can set this option
>> globally for all the list digests you receive at this point.
>> 
>> 
>> 
>> Send Rmt mailing list submissions to
>> rmt <at> ietf.org
>> 
>> To subscribe or unsubscribe via the World Wide Web, visit
>> https://www.ietf.org/mailman/listinfo/rmt
>> or, via email, send a message with subject or body 'help' to
>> rmt-request <at> ietf.org
>> 
>> You can reach the person managing the list at
>> rmt-owner <at> ietf.org
>> 
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Rmt digest..."
> 
> _______________________________________________
> Rmt mailing list
> Rmt <at> ietf.org
> https://www.ietf.org/mailman/listinfo/rmt
> 

Gmane