Subject: [clue] Fwd: New Version Notification for draft-kyzivat-clue-signaling-03.txt

From: Paul Kyzivat <[email-masked]>
Date: Thu, 13 Jun 2013 17:26:58 -0400

I just posted a new version of the signaling draft. Here are changes 
(from the change log):

       *  Added a syntax section with an XML schema for CLUE messages.
          This is a strawhorse, and is very incomplete, but it
          establishes a template for doing this based on elements defined
          in the data model.  (Thanks to Roberta for help with this!)

       *  Did some rewording to fit the syntax section in and reference
          it.

       *  Did some relatively minor restructuring of the document to make
          it flow better in a logical way.

The prior versions have received little comment.
PLEASE, PLEASE review this and comment!!!
There are many open issues in this looking for comments
or preferably proposed text.

	Thanks,
	Paul

-------- Original Message --------
Subject: New Version Notification for draft-kyzivat-clue-signaling-03.txt
Date: Thu, 13 Jun 2013 14:22:45 -0700
From: [email-masked]
To: Christian Groves <[email-masked]>,        Lennard 
Xiao <[email-masked]>,        Paul Kyzivat 
<[email-masked]>,        Christian Groves 
<[email-masked]>

A new version of I-D, draft-kyzivat-clue-signaling-03.txt
has been successfully submitted by Paul Kyzivat and posted to the
IETF repository.

Filename:	 draft-kyzivat-clue-signaling
Revision:	 03
Title:		 CLUE Signaling
Creation date:	 2013-06-13
Group:		 Individual Submission
Number of pages: 27
URL: 
http://www.ietf.org/internet-drafts/draft-kyzivat-clue-signaling-03.txt
Status: 
http://datatracker.ietf.org/doc/draft-kyzivat-clue-signaling
Htmlized:        http://tools.ietf.org/html/draft-kyzivat-clue-signaling-03
Diff: 
http://www.ietf.org/rfcdiff?url2=draft-kyzivat-clue-signaling-03

Abstract:
    This document specifies how signaling is conducted in the course of
    CLUE sessions.  This includes how SIP/SDP signaling is applied to
    CLUE sessions as well as defining a CLUE-specific signaling protocol
    that complements SIP/SDP and supports negotiation of CLUE application
    level data.

The IETF Secretariat

---

From: Christian Groves <[email-masked]>
Date: Fri, 21 Jun 2013 18:25:22 +1000

Hello Paul, all,

A few comments:
3.5.1 Clue Channel Lifetime
---------------------------
Should we say something about heartbeat mechanisms in the case the CLUE 
channel stays established. Is a transport level heartbeat sufficient 
(probably so), or would someone like an application level heartbeat?

4.1. Encodings represented in SDP
----------------------------------
2nd paragraph:
We should probably be clear what we mean. There is the individual 
encoding attributes that are already defined in CLUE. Then there is the 
“actual media encoding” i.e. codecs et.al. Do we mean both? Or the 
later? From the above syntax I guess you propose only the latter which 
would mean having to introducing equivalent SDP to the CLUE individual 
encoding attributes.

3rd paragraph - 1st sentence:
The encoding infromation is available for use at least by CLUE (in the 
next sentence it says that a consumer may use it). I guess what you’re 
trying to say is that media isn’t available until the ID is associated 
with SDP associated with media or similar?

3rd paragraph - 2st sentence:
Doesn’t the label need to be defined for the consumer to configure it? 
It probably should say “The media associated with a capture encoding 
will only become active if/when a CLUE encoding identity (label) is 
associated which the SDP defining the encoding and the Advertiser has 
received a Configure message confirming the capture encoding.”

3rd paragraph - last sentence:
I’m confused? Its says the consumer has insufficient information to 
select it? But two sentence above it says a consumer may configure an 
encoding that is not defined?

5.1. Independence of SDP and CLUE negotiation
----------------------------------------------
First sentence:
CLUE exceeding I don’t think is a problem. How about if the CLUE Max 
bandwidth is less the SDP bandwidth? I’m not sure how the encodingGroup 
attributes apply? "make reference to SDP contents" - This is very 
general should we narrow this only to refer to the group/label that ties 
the two together?

General
-------
There seems to be overlap between the included text from 
I-D.hansen-clue-sdp-interaction and other sections in the signalling 
document. I'm not sure of the procedure but I think it would be good if 
the draft editor can make changes to the text rather than cutting and 
pasting.

Regards, Christian

PS: I might be slow with my responses as I'm travelling.

On 14/06/2013 7:26 AM, Paul Kyzivat wrote:
> To: Christian Groves <[email-masked]>, Lennard Xiao 
> <[email-masked]>, Paul Kyzivat <[email-masked]>, 
> Christian Groves <[email-masked]>
>
>
> Status: http://datatracker.ietf.org/doc/draft-kyzivat-clue-signaling
> Diff: http://www.ietf.org/rfcdiff?url2=draft-kyzivat-clue-signaling-03
>
> Abstract:
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 21 Jun 2013 13:23:31 -0400

Hi Christian,

Thanks for being the first to comment!
I'm hoping others will now follow your lead. (HINT)

I ESPECIALLY NEED ROB TO RESPOND TO THIS.

> 3.5.1 Clue Channel Lifetime

I was thinking that the transport level heartbeat would be sufficient.

Also, one of the reasons for choosing this transport stack is that it 
will work well for NAT/FW traversal, especially in conjunction with ICE. 
In that case I believe there is an expectation that STUN keepalives will 
be sent to keep the NATs happy. Perhaps there should be a section on 
that. What do you think?

It would be nice to keep the application level free of such things.

> 4.1. Encodings represented in SDP

Note that this approach was first proposed by Rob. There seemed to be 
some interest in that, though perhaps not consensus. I adopted that 
approach here as a straw horse, looking to get consensus or some pushback.

What I intend here is that there is *no* representation of individual 
encodings in the Advertisement message. The one and only representation 
is what is present in the SDP. But the Encoding Groups are still 
represented in the Advertisement - consisting of a set of IDs or labels 
that each reference an individual encoding in the SDP.

So to answer your question, the m-line contains both.

> received a Configure message confirming the capture encoding.”

I'm trying to address the reality of the asynchrony of Advertisements 
and SDP O/A, while not trying to over constrain.

When an advertisement is sent, it will include some encoding groups, 
that contain IDs of some encodings. At the time the advertisement is 
received, an SDP that contains the definitions of the encodings may or 
may not been received. If the most recently received SDP doesn't have a 
definition of the encoding, then the receiver won't be able to 
understand it. So it would be stupid, but possible, to send a Configure 
that references such an encoding. All I'm doing is explaining what will 
happen in that situation: you will end up with a capture encoding that 
cannot be transmitted. But transmission can then begin if/when another 
O/A occurs that identifies that encoding / m-line, *and* that m-line is 
accepted by both ends during that O/A.

This does illustrate a limitation with this approach: Suppose an 
advertiser wants to advertise a new encoding. It needs to send an offer 
that includes the encoding, and it needs to send an advertisement that 
references it in an encoding group, making it available for 
configuration. It has to decide which to send first.

If an offer containing the SDP with the encoding is sent first, then the 
answer will need to be constructed without knowing if there will be any 
desire to use that encoding. If the answer accepts the encoding and then 
the answerer, after receiving the subsequent Advertisement, decides it 
doesn't need that encoding, then resources have been wasted. It will 
then take another O/A to shed those resources.

If an Advertisement that references the new encoding is sent first, then 
as above, the receiver has no basis to send a configure selecting it. 
This may be ok if it can just wait for the SDP before sending a 
Configure. But there is no *guarantee* that such an SDP offer will be 
coming soon. So how long should one wait before sending a Configure?

I think this means that this approach requires a bit more specification 
of the sequencing between advertisements and SDP. Perhaps we could say 
that if you send an advertisement that references an encoding, then you 
are obligated to send an offer asap that defines that encoding.

This was Rob's idea. Maybe he will comment. ROB - ARE YOU THERE???

Personally, I find this fairly discomforting. I think I would prefer to 
keep encodings in the advertisement. But I thought it worthwhile to 
explore this approach.

> encoding that is not defined?

I think I already covered this above. The consumer has insufficient 
information to make an informed choice. But he has sufficient 
information to make an uninformed choice. (I would like this capture, 
but the only encoding for it is currently unavailable to me. I'll just 
ask for it and see if I get an offer that defines it and that I can 
support.)

> 5.1. Independence of SDP and CLUE negotiation

As noted, I just copied this material from Rob's document.
While I have my own interpretation of it, rather than trying to channel 
Rob, I think it would be better to let him respond to this!

ROB - CAN YOU RESPOND HERE?

> the draft editor can make changes to the text rather than cutting and

I agree. I just consider this a transient stage. My adoption of Rob's 
proposal is tentative, to see how it flies. If we actually agree to go 
this way then we need to do a lot of cleanup. I just don't think its 
worthwhile until we get some agreement.

	Thanks,
	Paul

---

From: Robert Hansen <[email-masked]>
Date: Mon, 24 Jun 2013 20:15:10 +0100

Apologies for not having responded - I've been trying to find the time 
to write a proper set of updates I could run past Paul for integration 
into the draft but haven't managed it yet. I clearly need to do so, 
because without concrete proposals it's hard to weigh the pros and cons 
of things.

Some comment in-line.

> So to answer your question, the m-line contains both.

In a perfect world I think there's a good argument for the encoding 
groups to also be in the SDP, but that would require new syntax and is a 
lot less important than having the encodings there.

> keep encodings in the advertisement. But I thought it worthwhile to

I believe that this problem exists irrespective of where the encoding 
information goes - even if all the encoding information were in the clue 
advertisment the essential issue would still exist. So long as we have 
the premise that stream multiplexing is negotiated at the SDP level but 
that some information about that stream is outside SDP (in the clue 
advertisment) then accepting a new stream isn't atomic and we have this 
issue: if an SDP offer is received with three streams but the 
advertisment hasn't yet been received then the receiver will be unable 
to make a sensible decision about whether it wants to accept those 
streams, whether the encoding information about those streams is in the 
SDP or in the CLUE message.

When I've thought about this in the past I've generally felt it was best 
to leave it up to individual implementations how they deal with how best 
to deal with the fact they need information from two independant sources 
to make sensible decisions. However, as you point out some behaviour 
(such as accepting streams from an SDP on-spec before you see the 
associated advertisment when there's no guarentee when, if ever, that 
advertisment will arrive) is obviously sub-optimal.

Rather than mandate the timings of inter-related SDP and CLUE messages, 
though, I'd prefer to mandate the way the receiver deals with the 
messages it received (or at least highly recommend it). Adding the rule 
that a receiver should ignore any CLUE advertised element for which it 
does not have the corresponding SDP, and similarly must reject any SDP 
streams for which it does not have corresponding CLUE advertisment 
information, is straightforward and ensures that resources are never 
unnecessarily committed. The downside, that an additional O/A or clue 
message may be required, is a fixed cost rather than an open-ended one.

For instance, A advertises an additional stream to B by sending a new 
SDP offer and a new CLUE advertisment. In the first example, B receives 
the advertisment first:

* A sends an advertisment with stream X.
     (B must not send a configure for stream X, because it has not 
received the corresponding SDP).

* A sends an SDP offer with stream X.

* B sends an SDP answer accepting stream X.

* B sends a configure message requesting stream X.

In the second example, B receives the SDP first:

* A sends an SDP offer with stream X.
      (B cannot send an answer in response with an active stream X, 
because it has not received the corresponding advertisment).

* B send an SDP answer with stream X zeroed.

* B receives A's advertisment with stream X in.

* B sends a new SDP offer with stream X active.

* B sends a configure message requesting stream X.

* A sends an SDP answer with stream X active.

> ask for it and see if I get an offer that defines it and that I can

Indeed, and the proposal above would be to disallow such 'uninformed' 
choices.

> ROB - CAN YOU RESPOND HERE?

Ultimately I'd like to move any bandwidth and other encoding-related 
constraints out of clue and into the SDP, removing this specific issue. 
But that will probably depend on the final SDP syntax we end up using 
for multiplexing.

Generally, though, the rule is that the constraints of both SDP and CLUE 
are applied. If 4M has been negotiated in SDP and 2M in CLUE, the limit 
is 2M. If five streams have been asked for in a CLUE configure message 
but only three streams have been negotiated in SDP, only those three 
streams should be sent.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 24 Jun 2013 16:39:56 -0400

Rob,

I'm in general agreement with what you say.

The one exception is about "must ignore" parts of an advertisement where 
required SDP info is lacking.

I do think a sensible device will probably take this approach. But I can 
see no reason to mandate that. Doing so still leaves open the 
possibility that it will be violated. And in general it will be 
impossible for the advertiser to know if the configurer has behaved 
legally or not. (Because messages may arrive in a different order than 
they were sent.)

I can see no harm to anyone from allowing this seemingly stupid 
behavior. So why be more restrictive than necessary?

	Thanks,
	Paul