Subject: [Rmt] ALC on unidirectional and provisioned link - congestion control requirements

From: [email-masked]
Date: Tue, 3 Dec 2002 11:13:10 +0200

Hello

Having read through the excellent LCT and ALC drafts I believe the current drafts have a short-coming for unidirectional and provisioned links. Put briefly:

An explicit congestion control mechanism is not needed for totally provisioned unidirectional links that will not subsequently forward packets to the Public Internet.

Such cases are valid for massively scalable multicast and broadcast-like applications. For example, digital broadcast wireless and cellular wireless should be controllable by the network operator in many cases. Here, "portal" services can be provisioned (guaranteed bandwidth - fixed or otherwise) and supplementary congestion control in the IP-routed links is unnecessary. Also, in some of these cases clients/receivers will not have an always-on IP uplink to the router/network with which to implement IGMP or uplink signalled congestion control. ALC with its FEC and other functionalities is a very attractive protocol for these links and it makes sense to enable ALC-compliant applications on these links.

These comments also apply to "router filtering of a single layer" being used as a multiple rate congestion control method where different rates may be suitable on different downlink paths between router and receivers (e.g. DSL users vs.. 56K dial-up users).

However, the three existing drafts which deal with congestion control do not provide this kind of functionality (rmt-bb-pgmcc-01, rmt-bb-tfmcc-01, rmt-bb-webrc-03).

Furthermore, ALC (draft 08) states "The push model is particularly attractive in satellite networks and wireless networks.  In these environments a session may include one channel and a sender may send packets at a fixed rate to this channel, but sending at a fixed rate without congestion control is outside the scope of this document" (§1.1), "ALC is presumed to be used with an underlying IP multicast network or transport service that is a "best effort" service that does not guarantee packet reception, packet reception order, and which does not have any support for flow or congestion control" (§1.3), "Some networks are not amenable to some congestion control protocols that could be used with ALC.  In particular, for a satellite or wireless network, there may be no mechanism for receivers to effectively reduce their reception rate since there may be a fixed transmission rate allocated to the session" (§1.3, "Implementors of ALC MUST implement a multiple rate feedback-free con!
gestion control building block that is in accordance to RFC2357" (§2.2) and "When using a multiple rate congestion control building block a sender sends packets in the session to several channels at potentially different rates. Then, individual receivers adjust their reception rate within a session by adjusting which set of channels they are joined to at each point in time depending on the available bandwidth between the receiver and the sender, but independent of other receivers" (§2.2).

This seems to imply that receiver-router joins MUST be possible to be ALC-compliant even if the implementation would be otherwise compliant with RFC2357. A reliance on any kind of uplink signalling competes with the goal to be massively scalable so I believe that ALC can be genuinely improved by taking account of this kind of environment including unidirectional provisioned links.

Therefore, I would request a change to the ALC spec. to allow a implicit congestion control for these kinds of links. I.e. where the lower layers (or out-of-band mechanisms) already provide sufficient congestion control to protect "competing" packets and conform to RFC2357, as ALC is also very valuable for services over these links. (This would also avoid the need to produce a new, and not very valuable, draft just to specify a null-RMT-congestion-control for these links!). As the change is minor and would not effect compliance with RFC2357, I hope this would not delay the transition to experimental standard (i.e. the time in the RFC editor queue) at all.

How would you like to handle this?

All the best,
Rod Walsh.

========================
  Rod Walsh
  Nokia Research Center
  Tampere, Finland.
  [email-masked]
  +358 50 483 5632 
========================
_______________________________________________
Rmt mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rmt

---

From: "Michael Luby" <[email-masked]>
Date: Tue, 3 Dec 2002 13:19:41 -0800

I agree with you Rod, I think the LCT/ALC drafts add a lot more than just
the layering, and there are applications where congestion control (which is
why the layering is there in the first place) is inappropriate.  The only
impact the layering has on the information carried in the packet header
format is contained in the congestion control information (CCI) field, and
the format of this field is not specified in the LCT/ALC drafts.  The other
information contained in the LCT/ALC header is really quite useful in many
applications, including applications you mention of sending to the session
at a fixed rate for example in wireless or satellite environment.   For
example, there is the ability to name different objects being sent to the
session, there is a transport session identifier, there are indications of
end of session and end of object, ability to send timing information, and of
course the ability to identify the FEC data contained in the payload of the
packet.  This light-weight support is exactly the kind of information we
have found useful in all of our applications at Digital Fountain for the
past few years, including wireless applications working at a fixed rate
where there is no feed-back channel (in these apps, it makes no sense to use
multiple channels within a session because there is no ability of receivers
to dynamically join/leave channels and have any impact on consumed network
bandwidth).

I think the right way to approach this is the way I believe RTP did this: in
environments where congestion control is not possible/appropriate, e.g.,
where there is no backchannel, allow for a no congestion control option.  I
think the documents could be appropriately worded to mandate that this can
only be done in environments where there is a dedicated amount of bandwidth
a priori devoted to the session, i.e., something along the lines that you
suggest.  In this case, the CCI could be something as simple as the packet
sequence number, which allows the receiver to still compute packet loss
statistics (this is what we do for example in our wireless applications).

I think the plan is to move ALC from Experimental RFC status to Proposed
Standard RFC status aggressively, i.e., within the next couple of months, so
perhaps it would be best to make this change when it moves to Proposed
Standard (since it is essentially through the Experimental RFC status
stage).

Mike Luby

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, December 03, 2002 9:48 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: Re: [Rmt] ALC on unidirectional and provisioned link -
congestion control requirements

>Therefore, I would request a change to the ALC spec. to allow a implicit
conge
>stion control for these kinds of links. I.e. where the lower layers (or
out-of
>-band mechanisms) already provide sufficient congestion control to protect
"co
>mpeting" packets and conform to RFC2357, as ALC is also very valuable for
serv
>ices over these links.

I think you don't need or want ALC for such links.  The layering in
ALC is there to allow different receivers to go at different rates.
If all the receivers necessarily receive at the same rate, then you
don't need layered coding.  On the other hand, if the receivers
receive at different rates, then you want congestion control to match
the requested traffic to the available capacity.

 - Mark

---

From: [email-masked]
Date: Wed, 4 Dec 2002 14:10:09 +0200

Thank you Mike and Mark for the fast response,

I understand Mark's point that use of ALC without the selection of which layers are sent or with just a single layer does not take all the benefit of Asynchronous Layered Coding. However, as described by Mike, there are many services ALC provides which are useful even without selectable layered coding and it would not make a sense to create a separate FEC-orientated RMT protocol to provide these for transporting non-selectable-layered-coded sessions. So including the types of links I described earlier in the ALC scope makes alot of sense to me.

In essence my request is to allow "out-of-band" congestion control which meets the needs of RFC2357. This does not effect the core value of ALC, nor the goals for massive scalability and following RFC2357.

This would enable fixed rate (bandwidth provisioned) sessions over provisioned unidirectional links where the packets are not subsequently forwarded to the Public Internet. It would also allow router based congestion control where the links between this router and the senders (over the public Internet) follow one congestion control mechanism compliant with RFC2357, and the downlink(s) from the router(s) to the receivers may be provisioned - i.e. determined by a L2 congestion control. The second case is also important as aggregate downlinks (not on the public Internet) may be provisioned and the router(s) may select how to used these fixed rate links by forwarding only certain channels of inbound sessions over certain links. [I am pointing this case out as it is not entirely analogous to RTP where bandwidth is fixed per session].

I hope the value of this change is clear and evident. With your support I am sure ALC is able to include this case by the time it achieves proposed standard.

Cheers, Rod.

-----Original Message-----
From: ext Michael Luby [mailto:[email-masked]]
Sent: 03 December, 2002 23:20
To: Walsh Rod (NRC/Tampere)
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]; Michael Luby
Subject: RE: [Rmt] ALC on unidirectional and provisioned link -
congestion control requirements 

Mike Luby

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, December 03, 2002 9:48 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];

conge
out-of
"co
serv

 - Mark