1 / 8

RMT meeting

IETF 68 th – Prague meeting, March 2007 Vincent Roca (INRIA). RMT meeting. <draft-ietf-rmt-bb-fec-rs-02.txt> WGLC. Received good comments from Brian: comment 1: additional FEC Enc ID for the special case of RS codes over GF(2^8) / G=1 (one symbol/packet) benefit: more compact EXT_FTI

aquarius
Download Presentation

RMT meeting

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IETF 68th – Prague meeting, March 2007 Vincent Roca (INRIA) RMT meeting

  2. <draft-ietf-rmt-bb-fec-rs-02.txt> WGLC • Received good comments from Brian: • comment 1: additional FEC Enc ID for the special case of RS codes over GF(2^8) / G=1 (one symbol/packet) • benefit: more compact EXT_FTI • yes. Proposed FEC Enc ID is 5 (since FEC Enc IDs 3 and 4 are reserved by LDPC-*) • comment 2: “assign an "instance id" value for the underspecified small blk systematic FEC codes” (129) • yes. Mark? • NB: in practice it’s already done in our ALC lib and in Peltotalo’s ALC lib (we use FEC Inst. ID 0)

  3. <draft-ietf-rmt-bb-fec-rs-02.txt> WGLC… (cont) • Comment 3: editorial • we’ll clarify text. Thanks a lot!!! • Next step • new I-D version (next week) • we’ll also send a diff…

  4. <draft-ietf-rmt-bb-fec-ldpc-04.txt> WGLC • this version includes Mark comment (IETF’67) • FEC-OTI-Scheme-Specific-Info: string resulting from the Base64 encoding of the {PRNG seed; G} parameters • no comment received after WGLC • … but I found a couple of typos (e.g. a reference to an old FEC Enc ID 132 !) • new I-D version next week, sent along with a diff

  5. TESLA I-D update • several improvements • interval index of the authentication information becomes optional, text clarified, examples added • open point 1: clarify how to send “Direct Time Synch” requests/responses with NORM • what message type? what reliability? how to address feedback implosion risks?  under progress…

  6. TESLA I-D update… (cont’) • open point 2: how does an end-point (sender or recv) know how to interpret the EXT_AUTH? • Solution1: define an “Auth scheme ID” sub-field within the EXT_AUTH (what I assumed so far)… • with “Auth scheme ID”, several different schemes can be used at the same time, e.g. for NORM feedback… • but is there a real need? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HET (=1) | HEL |SchemID| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  7. TESLA I-D update… (cont’) • Solution 2: signal the format used out-of-band (e.g. in SDP descriptor). • okay if there’s no ambiguity: i.e. either a single auth scheme is used or there’s a way to differentiate the various dataflows • with ALC, a possible solution to avoid ambiguity is to use the “codepoint” (ALC-revised I-D, section 2.4) “As another example, it is possible that a different packet authentication scheme is used for different packets sent to the session. In this case, the mapping between the packet authentication scheme and Codepoint values could be provided in the Session Description.”

  8. TESLA I-D update… (cont’) • …but there’s no “codepoint” field with NORM • no problem with NORM if there’s a single auth scheme per direction, otherwise…

More Related