Subject: RE: [Rmt] EXP2ST: LCT, ALC and FLUTE channelisation - can we eliminate the crazy case?

From: [email-masked]
Date: Tue, 2 Aug 2005 00:12:45 +0300

Lorenzo asked for this issue to be highlighted in the mail list after I raised it in today's RMT meeting. Please comment...

LCT allows for 3 cases of channel differentialtion, one of which is troublesome. In psuedo formula form:

channelID = {S,D,P} = {sessionID(sourceIPaddr, TSI), dest(IPaddr), dest(UDPport)}

A) fixed(S), channel_differentiation(D), whatever(P)	-> OK (normal)
B) fixed(S,D), channel_differentiation(P)			-> OK (unusual?)
C) fixed(S), channel_differentiation(D,P)		 	->CRAZY (complex, unecessary)

[note, "channel_differentiation" is the part of the channelID that is actively used to uniquely Id the channel in the session].

C seems unecessary and overly complex in any case. It was also very problematic to describe in SDP, so without any use for it we didn't bother.

[A is the normal congestion control case and B is a corner case - both are easily describable by flute-sdp]

I proposed that we recommend that case C is not used. Alternatively we could outlaw it completely. I think it would only be necessary to spell this out in LCT (it may help clarity for ALC and FLUTE to then reference this point from LCT - I'll look once I get feeling back form the group).

Cheers, Rod.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Sunday, July 31, 2005 8:04 PM
> To: [email-masked]
> Subject: [Rmt] EXP2ST: LCT,ALC and FLUTE channelisation - can we
> eliminate the crazy case?
> 
> 
> When banging out the details for 3GPP and DVB use of FLUTE we 
> took a closer look at channelisation for the LCT, ALC, FLUTE 
> family. When we started describing the session (see 
> draft-mehta-rmt-flute-sdp-03.txt) it became clear that there 
> are 3 cases for distinguishing channels.
> 
> Channels are defined by 4 parameters:
> (IP_source_address, TSI, 
> IP_destination/group_address_destination_port_number). 
> Thus channels can be differentiated based on each of these cases:
> 1.	Differing destination IP addresses (ports may also change)
> 2.	Differing port numbers using the same IP destination 
> address for all
> 3.	Both differing and mixed, where several channels use 
> the same IP destination address different ports and several 
> IP destination addresses are used.
> 
> Generally (1) should be used (for enabling CC (congestion 
> control) use of channels). However, there are potential use 
> cases for (2) since application layer CC is feasible. No one 
> has so far come up with a compelling use case for (3) and 
> this could be horribly complex.
> 
> The flute-sdp I-D does not have a way of describing case (3) 
> in any case.
> 
> However, now I am proposing to EXPLICITLY ELIMINATE THE 
> UNNECESSARY MULTI-ADDRESS + MULTI-PORT CHANNEL 
> DIFFERENTIATION case (3) by stating this in LCT:
> 
> The identification of channels of a session SHOULD be 
> differentiated primarily based on their IP destination/group 
> address, such that no more than one channel should use a 
> single IP destination/group address. However, more than one 
> channel is delivered using a single IP destination/group 
> address, meaning that the destination port number is also 
> primarily used to identify channels, the destination port 
> number MUST differentiate the channels alone, such that the 
> same IP destination/group address MUST be used for all the 
> channels of a session. This disallows the unnecessary and 
> complex case of multiple channels across multiple ports 
> unevenly distributed over multiple addresses in any situation.
> 
> 
> Sound good?
> 
> Cheers, Rod.
> 
> _______________________________________________
> Rmt mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rmt
> 

_______________________________________________
Rmt mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rmt

---

From: "Michael Luby" <[email-masked]>
Date: Mon, 1 Aug 2005 15:02:04 -0700

By "channel_differentiation" I presume you mean within an ALC/LCT session
and you are referring to the different channels within the session that can
be used for layered congestion control, in which case the receiver want to
receive data from some but perhaps not all the channels at any point in
time, and wants to be able to add/remove channels dynamically during the
course of the session. I'm assuming this is what you mean in my response
below.

A is the usual case.

B is not useful for multicast congestion control, since receivers join and
leave channels using an IP multicast addresses, not port numbers.
B is useful for unicast congestion control (since receiver can send
join/leave message all the way back to the sender and say which channels
they want to receive based on port number -- which we have used it in the
past) when you have a sender that is sending data both multicast and
unicast, and you want to use essentially the same type of congestion control
in the receiver for both.  So, I would vote to allow B.

C is crazy, complex, unnecessary.

Mike

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Monday, August 01, 2005 2:13 PM
> To: [email-masked]
> Subject: RE: [Rmt] EXP2ST: LCT,ALC and FLUTE channelisation - can we
> Importance: High
> Lorenzo asked for this issue to be highlighted in the mail list
> after I raised it in today's RMT meeting. Please comment...
>
> [note, "channel_differentiation" is the part of the channelID
> that is actively used to uniquely Id the channel in the session].
>
> C seems unecessary and overly complex in any case. It was also
> very problematic to describe in SDP, so without any use for it we
> didn't bother.
>
> [A is the normal congestion control case and B is a corner case -
> both are easily describable by flute-sdp]
>
> I proposed that we recommend that case C is not used.
> Alternatively we could outlaw it completely. I think it would
> only be necessary to spell this out in LCT (it may help clarity
> for ALC and FLUTE to then reference this point from LCT - I'll
> look once I get feeling back form the group).
>
> Cheers, Rod.
>
>
>
>