IETF 67 RMT WG Minutes
Tuesday, Afternoon Session I 1300-1500
======================================
Note taker: Mark Watson (MW)
--------------------------
1) Agenda Bashing
5 min - All
- Notewell: sign blue sheets & state your name at the microphone
Lorenzo Vicisano (LV) welcomed Brian Adamson as new working group co-chair.
--------------------------
2) WG Progress
20 min - WG Chairs & Document Editors
(Several documents are ready for Last Call or IESG submission)
LV: The FEC and Raptor building block (BB) documents. have passed working group last call (WGLC) and are ready for submission to IESG. Other RMT Working Group BB documents are also ready for working group last call. The status of the Protocol Instantiation (PI) documents depend upon the outcome of planned security discussions later in the meeting.
Updated Documents
- draft-rmt-fec-bb-revised-04 - passed WGLC, ready for IESG
- draft-ietf-rmt-bb-fec-ldpc-03
Vincent Roca (VR): The FEC-LDPC BB is ready for WGLC.
MW: Some sections on OTI need updating to remove FLUTE-specific handling and use "scheme-specific info".
LV: An Action Item was assigned to Vincent to update and remind chair to issue WGLCs.
The "draft-ietf-rmt-flute-revised-02" document was discussed:
VR: EXT_CENC should be moved to ALC
Lakshminath Dondeti (LD): I don't see any problems with this extension being described in the FLUTE BB.
LV: I recommend we resolve this on the mailing list and assign an Action Item to VR to start the discussion.
The "draft-rmt-bb-norm-revised-02" document was discussed.
Brian Adamson (BA): This document is ready for WGLC. The status of the "draft-rmt-pi-norm-revised-03" is dependent upon the outcome of the security discussion planned for later in the meeting.
Other Active Documents
- draft-ietf-rmt-bb-fec-raptor-object-04 - passed WGLC, ready for IESG
- draft-ietf-rmt-bb-fec-rs-01 - ready for WGLC
- draft-ietf-rmt-bb-lct-revised-04 - status pending the security discussion later in the meeting
Expired Documents
- draft-ietf-rmt-pi-alc-revised-03 - status pending the security discussion later in the meeting
- draft-ietf-rmt-bb-fec-basic-schemes-revised-02 - ready for WGLC, needs to be resubmitted by MW
MW: The FEC Basic Schemes BB is ready for WGLC. No changes have been made or are needed.
Stephan Wenger (SW): Is this the document with the No-Code FEC Scheme?
LV: Yes
LV: Current Milestones (see slides):
Sep 2005 - Submit remaining congestion control building blocks (TFMCC, PGMCC) for publication. The TFMCC is done and has been published as RFC 4654. The PGMCC needs further work, but there is no time or interest from authors. I propose to drop ths as a WG item. Note that it covers cases which are already covered by TFMCC so we do not lose anything. Agreed.
No comments on other milestones.
New proposed milestones (see slides):
Magnus Westerlund (MWe): Seems optimistic to have security work done by April 2007. July 2007 is more realistic.
BA: Agree with Magnus. July seems reasonable. This would allow for submission of updated documents by the March 2007 WG meeting, and provide a time for feedback and further editing.
MWe: Likely, after Chicago is the earliest realistic date for submitting final versions (August 2007).
--------------------------
3) Finite Geometry LDPC Code (FG-LDPC) Presentation
20 min - Wu Yuchun (Huawei Hisi Company, Ltd)
Wu Yuchun (WY) presented on this topic (see slides)
VR: Next thing to do is to show simulation results to show whether this is interesting..
Mike Luby (ML): Didn't use that criteria for any other FEC Schemes?
VR: Agree, but at least something should be shown
WY: For one FG-LDPC code we have measured an Inefficiency ratio of 1.0145, but have not done many simulations yet
LV: Agree that previously we have not looked at performance, but there is some overhead in standardising something and so we should understand the operational parameters and performance in order to decide whether to do the work. This information should be in the draft.
WY: This work can be done later.
--------------------------
4) Framing ALC Packets over Connection-Oriented Transport
10 min - Imed Bouazizi / Stephen Wenger
SW: The "draft-bouazizi-rmt-alcframing-00" was presented with apologies for this being after the -00 deadline (See slides).
BA: You could use this to tunnel ALC over NORM - may not be obvious what the use-case is, but there is! e.g. use ALC end-to-end with "NORM tunnels" on problematic links.
LV: In the TCP case, how does ALC flow control and congestion control interact with TCP flow and congestion control? May need buffer at head of TCP tunnel as it may not be able to keep up with multicast flow.
SW: You're talking about problem where TCP tunnel can't keep up with incoming ALC flow rate ? No immediate answer is available.
MWe: Depends on where you do things - if you do TCP from the original source then no problem. Interesting issues if you start the TCP at a middlebox.
Gorey Fairhurst (GF): how can it work with receiver driven congestion control using multicast layers ? Not simple.
SW: 3GPP people want to do this due to higher cost of multicast link, unless there are many receivers.
ML: This seems to be focused on unicast, but this group is multicast. So, is this encapsulation in scope? Is there IPR on this?
SW: No IPR that I know of. To be within RMT scope might require charter update, but likely too closely related to RMT work to do anywhere else.
GF: TCP seems to be the complex part - if you sent it over UDP then everyone would say OK.
SW: I will relay this feedback to the authors.
VR: Can you be more clear on the problem statement ? It's not clear in the draft.
SW: Yes.
Lars Eggert (LE): TCP part doesn't worry me, but it would worrying if you start to turn off TCP mechanisms such as congestion control.
ML: How does layered congestion control work with this. Over UDP it's easy to see how it works, but TCP looks too complex
MWe: Could interwork between multicast congestion control and TCP by interworking point joining more or less groups depending on downstream TCP bandwidth. You propose SDP but setting up a unicast connection requires bi-directional communication.
SW: I will feed these points back to the author.
LV: If TCP could be avoided then it could be much easier. If it cannot be avoided then we might be able to find a solution but do we want to ?
SW: Have to watch for danger of IETF refusing to work on things that 3GPP want. 3GPP might just do it themselves.
MW: 3GPP/IETF cooperation works best when 3GPP provide requirements to IETF rather than solutions.
MWe: I am working on draft on FLUTE over unicast UDP - will forward to list (http://www3.ietf.org/proceedings/06nov/IDs/draft-lohmar-mmusic-rtsp-flute-00.txt)
--------------------------
5) RMT Security Issues Draft & Discussion
30 min - Vincent Roca (INRIA)
- draft-adamson-roca-rmtsec-issues-00
Presentation by Vincent Roca (see slides)
ML: Where is this going ? Will this become informational ? How do we get to publishing the PI documents ?
BA: At least one mode of secure operation is needed in each PI. For example, maybe an IPSec profile should be added to PI documents and this would be sufficient for publishing them, with the appropriate caveats (scalability limits, etc) outlined along with the profile. This hopefully can be done quickly within to milestone goal dates discussed earlier.
MWe: The group could establish one common document about threats/security issues for all the PIs.
BA: Yes, like original design guidelines for RMT - The security documents could be considered an extension of that.
ML: But doesn't this need to be normative
LV: No - not required to implement security - just required that we describe security solutions.
GF: Original idea was a document which looked at the threats and what layers they should be solved at.
MWe: PIs need to have at least one normative security solution
BA: Issue is that this initial security solution might not be as scalable as the protected RMT protocol and so there will still be a need for further security work in the longer term.
LV: Another goal for this document would be to identify gaps in what MSec is doing and maybe produce requirements
BA: Yes - text in PI should also describe applicability of the defined solution.
LV: Should work in parallel on this document and the minimal security solution for the PIs.
BA: Should the current "draft-adamson-roca-rmtsec-issues-00" be made a working group document?
LV: Anyone against ? (No objections raised) Agreed.
GF: I encourage people to review this - needs input from people who are experts in the individual protocols.
BA: IPSec security profile for ALC and NORM could be similar - could also leaverage other work such as RFC4552
GF: MSec assumes bi-directional negotiations and FLUTE assumes unidirectional - might not transfer very well
BA: Do we need to deal with replay attacks ?
GF: Yes, replay of synchonisation points in ALC session could confuse receivers
ML: What about TESLA ? That seems more appropriate for unidirectional
VR: Should we present this draft in MSec ?
LD: (didn't catch comment)
LV: Could be useful, but they met already this time - next time
MWe: How important is confidentiality at the transport layer - is it needed at all or do we rely on application layer ?
BA: Yes, could be important for NORM since there is information which indicates user participation and there might be privacy requirements associated to that.
GF: Also could be an issue for FLUTE, since people can observe the progression of a session.
BA: Could consider transport encapsulation which isn't necessarily IPSec - e.g. RMT equivalent of SSL that would protect RMT protocols headers as well.
LV: Seems interesting and should be studied but we also need to focus on the primary requirement
LD: Application layer protocols that want to use IPSec need to produce a set of requirements explaining what they want to achieve for review by the security area - IPSec may or may not be the best solution
--------------------------
6) Open Discussion, Related Work & Announcements
VR: Recently discovered that FLUTE is covered by Nokia IPR. IPR disclosure made in February 2003 with initial ALC and "FDALC". In 2004 patent was issued. FLUTE published shortly afterwards and Nokia disclosure on FLUTE made in 2006. Contacted Nokia and license is required for FLUTE implementations under RAND terms.
SW: I will take action to investigate this - was not aware until recently
LV: Should we do anything about this ? Perhaps define an alternative version of FLUTE ? Remember the core technology is ALC.
(Some support for this comment - didn't catch names)
MW: Looks like original 2003 disclosure was on "draft-paila-rmt-fdalc" and no disclosures were made on any FLUTE documents until 2006. Usually if there is no disclosure on a revised document with a different name then it means the IPR has been removed. Issue needs to be raised outside this group.
SW: Please take care not to address issues which are inappropriate for mailing list on the mailing list
LV: Request Nokia to clarify situation on the mailing list and then we'll discuss from there