[Rmt] FLUTE SDP specification - open issues thread 2

[<[e-mail]>]

Hi again all

Two more points to raise for the whole group to consider, the 2nd is CRITICAL (potentially)...

4. "Normative" is only defined in a fuzzy way, but in terms of "essential reading to understand the present document", actually LCT, ALC, FEC BB and Basic FEC schemes are not essential. SDP-FLUTE and FLUTE themselves provide enough background RMT info. We we're thinking of moving this list of 4 from the Normative references section to the Infornmative. Here's a great chance to flame us for getting the IETF Tao completely wrong! (Or congratulate us on our insightful interpretation of IETF documentation protocol).

5. FLUTE might be v2, but so might LCT and ALC!!! Separately the issue of "is this FLUTE v1 or v2, because of new (incompatible?) FDT schema" has been raised. But an (LCT) RFC3451 sender can break an RFC 5651 receiver (aka LCT experimental RFC sender and standards track RFC receiver). RFC3451 has a couple of header flags for the SCT and ERT header options, whereas RFC5651 makes this header potition Res (reservered) and set to 00, and ignored by a receiver. However the exp sender using these flags and the corresponding 32 or 64 bits of header would totally confuse a std track receiver. Worse still, if the time stamps co-incidentally match some header extension designations things get really funky. As stands, this implies that RFC5651 is not backwards compatible and so needs a new version number. The easier fix, it to change receiver behaviour from "ignore Res bits" to "parse Res bits and if either are set (to 1), then treat as an error case and reject the packet" -> which would not break either ends and so wouldn't need a version number update. (I imagine there must be a tried and trusted mechanism for tiny corrections like this in the IETF - right?)

Do we know of any other LCT-LCT+ or ALC-ALC+ incompatibilities?

Cheers, Rod & Jani



ext Jani Peltotalo wrote:

Dear RMTers,

We are currently updating the FLUTE SDP specification and at this point
we need to clarify three issues:

1. Our understanding is that ALC, LCT and FLUTE sessions must
originate from a single sender and therefore from a single IP address.
There is some confusing text of discussing ASM/SSM models in the ALC,
LCT and FLUTE specifications. It is our understanding that ASM/SSM
discussion only relates to IP level routing and (e.g., IGMP) joining of
IP multicast groups. Does anyone disagree with this? (And more
critically is anyone aware of implementation that is incompatible with
our understanding.)

2. FLUTE SDP defines the Composite Session token so that multiple FLUTE
sessions can be described in a single SDP object/instance/file (for
efficiency and encapsulation). To enable this the 05-version of the
specification promotes one media (channel) to be the Primary Media where
things like source IP address are defined for all media / channel for a
single FLUTE session. The specification currently says: "The first media
line declared for a Composite Session group is the Primary Media.".
However, we propose to change this to: "The first (leftmost) mid value
declared for a Composite Session group is the Primary Media.". This
should make reading and writing the SDP simpler and less prone to
errors. Because of the convention of declaring the group's mid values in
the same order as the media lines we anticipate no compatibility
breakages. Does anyone disagree with this?

3. ALC, LCT and FLUTE specify: "Each TSI MUST uniquely identify a
FLUTE session for a given source IP address during the time that the
session is active and also for a large time before and after the active
session time.". In SDP, the t-field is mandatory and this field is used
to specify precise time. We would like to fully specify what is meant by
large time. We propose 60 minutes. We will also clarify the best
practise use of SDP session times (especially with unbounded and
permanent sessions) in MMUSIC working group. Will this make anyone happy
on unhappy?

BR,

Jani Peltotalo
_______________________________________________
Rmt mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/rmt