Re: [MMUSIC] "splitting" a bundle

[Paul Kyzivat <[e-mail]>]

Inline

On 4/25/13 3:34 PM, Dale R. Worley wrote:
>> From: Paul Kyzivat <[e-mail]>
>>
>> This has come up in CLUE, and pertains to cases where not all media
>> processing equipment is at the same address. In such cases bundling may
>> be supported, but more than one bundle may be required.
>>
>> When this happens on the offering end the offerer can propose multiple
>> bundles from the beginning. But when it is the answerer that needs
>> things in separate bundles then it will need to "split" (partition) the
>> offered bundle into multiple bundles. You can view this as a variant of
>> (1)+(3) below.
>
> Some further thoughts on splitting an offered bundle:
>
> One consideration is that when the answerer wants to split an offered
> bundle, how does it do so in a way that takes into account what the
> offerer wants?
>
> For instance:
>
> 1. A offers a bundle 1,2,3,4.
>
> 2. B cannot bundle 3,4 with 1,2.
>
> 3. So B replies with bundle 1,2 and rejects 3,4 (or accepts them
> unbundled).
>
> 4. Now B offers bundle 1,2 and bundle 3,4.
>
> 5. A can accept both bundles, so A accepts bundle 1,2 and bundle 3,4.

Yeah, this is what I had in mind.

> This is somewhat inefficient, since it takes two O/A cycles, but it's
> simple, since A doesn't need to signal to B in some way what bundlings
> it is willing to accept (e.g., with the hierarchial bundling concept
> I've talked about).
>
> Now suppose A wants to bundle 1,2,3,4 and 5,6,7,8, but B wants to
> bundle 1,2,5,6 and 3,4,7,8.  The best bundling that can be achieved is
> in four pairs, bundle 1,2, bundle 3,4, bundle 5,6, and bundle 7,8.
> The best possible pattern for A and B to negotiate this would be
> something like this:

This is "best" in terms of maximizing the possible bundle sizes while 
minimizing the number of O/A cycles.

> 1. A offers bundle 1,2,3,4 and bundle 5,6,7,8.
>
> 2. B accepts bundle 1,2 and bundle 5,6 and rejects 3, 4, 7, and 8.
>
> 3. B offers bundle 1,2, bundle 5,6, bundle 3,4, and bundle 7,8.
> (Although it is willing to bundle 3,4 with 7,8, it remembers from A's
> offer that it was unwilling to do so.  So B is limited to bundling the
> four m= lines into two pairs.)

This seems a reasonable strategy.

> 4. A accepts bundle 1,2, bundle 5,6, bundle 3,4, and bundle 7,8.
>
> We have to make sure that A doesn't attempt to start a third cycle to
> see if it can get 1,2 bundled with 3,4, etc.

Another possibility would be for B offer bundles 1,2 and 5,6 because 
they already are in place, and 3,4,7,8 in hopes that it might be 
acceptable. Then A would refuse 7,8 and start another offer with 7,8 as 
a separate bundle. This is less efficient in this case, but makes fewer 
assumptions about the capabilities of A.

This seems like a bad choice. 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.)

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.

Having both as options makes things complicated. It could result in both 
sides waiting for the other to act. And having A make the second offer 
becomes a sort of "fetch a rock" exercise. 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."

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.

> 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.

	Thanks,
	Paul