Subject: [Rmt] FLUTE SDP specification

From: Jani Peltotalo <[email-masked]>
Date: Wed, 23 Jun 2010 20:29:51 +0300

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

---

From: "Luby, Michael" <[email-masked]>
Date: Wed, 23 Jun 2010 13:39:30 -0700

One comment below.

> permanent sessions) in MMUSIC working group. Will this make anyone happy
I can imagine a session going on for days, and having receivers come in and
out of coverage over hours, so having only a 60 minute buffer on each side
of the session in terms of uniqueness of the TSI seems very dangerous.
Multiple days seems a much safer bet.  Is there any reason to make this a
much smaller time period, i.e., a lack of TSI namespace that makes it
imperative to reuse TSIs very quickly?

---

From: <[email-masked]>
Date: Mon, 28 Jun 2010 14:59:49 +0200

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,

BR,

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

---

From: <[email-masked]>
Date: Mon, 28 Jun 2010 17:39:08 +0200

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

---

From: <[email-masked]>
Date: Tue, 29 Jun 2010 10:21:34 +0200

Hi WEBRC folk

>From this text from the WEBRC RFC3738...

"Before joining a session the receiver MUST know the mapping between the
CNs and the channels. Upon joining the session or shortly thereafter, it
SHOULD have the values of LENP_B, BCR_P, TSD, P, N, L, Q and T. Some of
these values may be computed or measured once the receiver has joined
the session. For example, the receiver MAY obtain LENP_B and T from the
first packet received from the base channel, and the receiver MAY
measure BCR_P once it is joined to the base channel.  The values of P, Q
and TSD MAY be fixed to default values built into the receiver that do
not change from session to session, and the value of N MAY be computed
as T-Q.  The receiver SHOULD know whether the sender is employing a
technique to produce constant aggregate rate as described in [8]."

Does anyone have a perspective on how trivial/complex and rapid/stalling the in-band detection or calculation would be for:
1. LENP_B - calculated from from first packet. That's minimal effort - right?
2. T - calculated from from first packet. That's minimal effort - right?
3. BCR_P - measured after joining. What kind of delay and processing is introduced?
4. N - simple calculation, no problem.
5. TSD, P, Q - must be communicated out of band. Are these likely to be fixed for practically all cases?
6. L - must be communicated out of band - right?

We're thinking about a flag for "constant aggregate rate" - would the rate need communicating instead?

Also, we're figuring out the CN semantics and whether ordering (and not explicit labelling) is sufficient.

Cheers, Rod.