RMT meeting

1
RMT meeting

• IETF 68th Prague meeting, March 2007
• Vincent Roca (INRIA)

2
ltdraft-ietf-rmt-bb-fec-rs-02.txtgt WGLC

• Received good comments from Brian
• comment 1 additional FEC Enc ID for the special
  case of RS codes over GF(28) / G1 (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 its already done in our ALC lib
  and in Peltotalos ALC lib (we use FEC Inst. ID 0)

3
ltdraft-ietf-rmt-bb-fec-rs-02.txtgt WGLC (cont)

• Comment 3 editorial
• well clarify text. Thanks a lot!!!
• Next step
• new I-D version (next week)
• well also send a diff

4
ltdraft-ietf-rmt-bb-fec-ldpc-04.txtgt WGLC

• this version includes Mark comment (IETF67)
• 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 theres no ambiguity i.e. either a
  single auth scheme is used or theres 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 theres no codepoint field with NORM
• no problem with NORM if theres a single auth
  scheme per direction, otherwise