Re: [MMUSIC] "splitting" a bundle

Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 30 April 2013 16:02 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65EC321F934C for <mmusic@ietfa.amsl.com>; Tue, 30 Apr 2013 09:02:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.137
X-Spam-Level:
X-Spam-Status: No, score=-0.137 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lh4eVLAbcAci for <mmusic@ietfa.amsl.com>; Tue, 30 Apr 2013 09:02:30 -0700 (PDT)
Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 5437C21F85C3 for <mmusic@ietf.org>; Tue, 30 Apr 2013 09:02:29 -0700 (PDT)
Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta05.westchester.pa.mail.comcast.net with comcast id WAW61l0040SCNGk55G2V9q; Tue, 30 Apr 2013 16:02:29 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id WG2U1l00t3ZTu2S3VG2Uq4; Tue, 30 Apr 2013 16:02:29 +0000
Message-ID: <517FEB14.3000407@alum.mit.edu>
Date: Tue, 30 Apr 2013 12:02:28 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: "Dale R. Worley" <worley@ariadne.com>
References: <201304091539.r39FdjqJ2253833@shell01.TheWorld.com> <516466C5.1070201@alum.mit.edu> <201304251934.r3PJYupZ3410480@shell01.TheWorld.com> <517A9991.3060901@alum.mit.edu> <201304292159.r3TLxCQT3757057@shell01.TheWorld.com>
In-Reply-To: <201304292159.r3TLxCQT3757057@shell01.TheWorld.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1367337749; bh=6MpoUnnPOgqltPkBCbNpI6Aal13Zz2i/oC6vNWSgGv4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=I3byUD8+H0zbFSpqesVTz/MktuCmOC3+Js+WVxDkj2cdPFidVoWc5TC2KLLfRVj5R 1P4vvoJ3mBJG+1J4CSvPclALlMjmUJcHprNq1/qTE1wG1TlnrHvXfyJcx2VpzE41uk 5/yTlrsBN2Rj5ehZlW/K/ltG2XCBnWvxixdQsdadvlfL6b+LkmPARhcp5GJvdwRG9e J3vODgEISQpKIu2+YMQNOlCXdn+ca0CIZ6aY+uSZE5LUxLTWzNNgRFFHAO21iE/TYS gX9ZJccEIbOqzvLiPaiEX86cnDnqOTdF7Uq5V9DuDQfP4E8X0KfmhhN/iHJG5QNbHA T9tKAurQ1KtnQ==
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] "splitting" a bundle
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Apr 2013 16:02:36 -0000

On 4/29/13 5:59 PM, Dale R. Worley wrote:
>> From: Paul Kyzivat <pkyzivat@alum.mit.edu>
>>
>> I only bring it up because past experience
>> with O/A has shown that it is generally better for an offerer to say
>> what they want without making value judgements about the other party. It
>> becomes especially important if it turns out that the party you are
>> sending the offer to turns out to be different from the one you talked
>> to last. (That probably is nonsense here if these O/A cycles are
>> back-to-back.)
>
> The difficulty in this case with always offering everything you want
> is that the process never ends:  Each endpoint *wants* to bundle m=
> lines that the other endpoint can't accept.
>
> OTOH, you have to worry about the possiblity that at this moment, the
> other endpoint is not the endpoint you negotiated with previously.

Yep!

> A solution is that if the endpoint is sending an offer to effect
> bundling between m= lines that it disconnected from an *immediately*
> preceding offer, the endpoint should offer no bundling that was not
> proposed in the preceding offer.  New offers generated for other
> reasons would offer all the bundling the endpoint is willing to
> support.

I think I agree with what you mean, but not with what I you wrote.
I think you mean:

"A solution is that if the endpoint is sending an offer to effect
bundling between m= lines that it disconnected from an *immediately*
preceding offer, the new offer should not disturb the bundles that
were accepted in the prior answer. New bundles may be offered including 
m-lines refused in the prior answer as well as new m-lines. New offers 
generated for other reasons would offer all the bundling the endpoint is 
willing to support."

This allows the 2nd O/A to introduce the remainder of the split bundle.

>> In all of the above, the behavior of B only makes sense if B feels it
>> *needs* all of these streams. Another possibility is that B simply
>> rejects the streams it can't accept when bundled as proposed, but
>> doesn't initiate another O/A cycle. Then if A feels those are important,
>> *it* can send another offer with them separately bundled.
>
> The difficulty with that is that A doesn't know whether B rejected
> them because it couldn't deal with the bundling or because B was
> unable to utlize the m= line for some other reason.  A would have to
> send a number of probes to determine the answer.

For this to be practical we would have to come up with a way to signal 
the *reason* those m-lines were refused. Preconditions might be one way.

>> But having B make the second
>> offer means it may need to take on faith "I don't know if these streams
>> are important, but my peer wanted them so I'll try to establish them."
>
> B would only include the stream in a second offer if B would have
> accepted the stream un-bundled, which means that B knows that A wants
> the stream (whether or not A considers it "important") and that B can
> support it, in which case we assume that the penalty for supporting
> the stream without bundling is lower than the penalty for not
> supporting the stream at all.

This will probably be ok. But we need to recognize that it is a slight 
leap of faith.

>> These cases requiring multiple O/A cycles to get things arranged as
>> desired are starting to smell to me like the kinds of situations that
>> preconditions were designed for. Perhaps a new "bundle" precondition
>> would provide a way to sort out responsibilities and realize when to
>> keep trying and when to give up. But many consider preconditions too
>> heavy weight to use in practice. And they could prove difficult in JSEP.
>
> It does resemble precondition situations.  But we can arrange for
> exactly two O/A cycles to determine the maximal bundling that both
> endpoints can support.

It seems so.

>>> But if either side initiates a re-offer for some other reason, the new
>>> offer should be the biggest bundling the offerer is willing to
>>> support.
>>
>> You mean, in the above case, after having agreed on bundles 1,2 ; 3/4 ;
>> 5/6 ; 7,8 if B decides it wants to add another stream 9 it should offer
>> 1,2,5,6 ; 3,4,7,8,9 ???
>>
>> I *think* the new offer should include the new bundles in their current
>> operational form, with only one address/port per bundle. Doing otherwise
>> would disrupt the functioning of the current streams. Stream 9 could be
>> added to one of the existing bundles in the offer, but should have a
>> separate address/port.
>>
>> That will probably break a scenario that is trying to do a 3pcc
>> transfer. I suspect that doing such a thing with bundled streams is
>> going to be *hard*, and will need to be considered separately.
>
> The question is whether B thinks A might have been replaced by A'.

In general I think we can assume that coincidences don't happen much. In 
particular, if conditions have changed at one endpoint such that it 
spontaneously needs to make a new offer that changes things from the 
current state, then it is exceedingly unlikely that the other endpoint 
will simultaneously have a change of state that it needs to introduce in 
the answer to that offer.

> Now that you mention it, if B adds stream 9 (generating a new offer
> for internal reasons), then it is very unlikely that A has been
> replaced.  But if B receives an offerless INVITE (demanding that B
> produce an offer), then A might well have been replaced.

Yes, the offerless invite should be viewed as a solicitation for the 
full set of desires of the receiver.

> If B receives an offer, there are three cases:
>
> The offer may be from an A', in which case it's OK if B gives the best
> response it can (according to the previous plan), and does a re-offer
> if it needs to create new bundles to split an offered bundle.
>
> The offer may be from A, generated for internal reasons, in which case
> it looks very much like the previous SDP.  But, e.g., added m= lines
> may be bundled in a way that B can't accept and may require B to
> produce a second offer.

One thing to clarify in a case like this is how such an offer (adding a 
new m-line to an already active bundle) should be structured. I think, 
for practical reasons, it should have a single address/port for all of 
the m-lines that had previously been bundled. Not doing so will disturb 
the ongoing flows.

This *does* mean that it might get in trouble if the recipient turns out 
to be B' rather than B, and B' doesn't support bundle. Barring 
coincidences, this shouldn't happen with an unsolicited offer.

> The offer may be from A, generated due to receiving an offerless
> INVITE from an intermediate 3PCC controller, in which case (we assume)
> it specifies the maximal bundling that A can support.  That may
> require B to produce a second offer.

The offerless invite *might* be an indication that B has been replaced 
by B'. But there are also uses of offerless invites when that hasn't 
happened. And we can't screw things up in those cases.

If B has not been replaced, then I think it remains important that the 
existing bundles not be disturbed. So if that is a possibility, then A 
should send an offer that has the existing bundles as they are. If it 
turns out that B has been replaced by B', then that may be sub-optimal. 
And if B' doesn't support bundling, then it may not work at all.

It would be nice if we had a way, in the offerless invite, to send 
something so the receiver could discover if it was talking to the same 
party as before. AFAIK we don't have a way to do that.

> So it looks like we can soften the rules to:
>
> If an endpoint makes an offer for what it sees as a new dialog, or due
> to receiving an offerless INVITE, it must offer the maximal bundling
> it supports.

As noted above, I don't think this works.

> If an endpoint receives an offer, it answers with the maximal bundling
> that it supports that is a subset of the offered bundling.  (I say
> "subset", as the answer necessarily has no more bundles than the
> offer.)  The endpoing may then make a second offer that offers the
> maximal bundling that it supports that is compatible with the received
> offer.  ("Compatible" in the sense of bundling no two m= lines that
> were not bundled in the offer.)

Presumably in the 2nd offer, if a new bundle is proposed, then all the 
m-lines in that offer can share a single address/port, because support 
for bundling is already known.

	Thanks,
	Paul