headers
Rod.Walsh | 3 Dec 2002 10:13
Picon

ALC on unidirectional and provisioned link - congestion control requirements

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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Luby | 3 Dec 2002 22:19
Favicon

RE: ALC on unidirectional and provisioned link - congestion control requirements

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).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rod.Walsh | 4 Dec 2002 13:10
Picon

RE: ALC on unidirectional and provisioned link - congestion control requirements

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:luby <at> digitalfountain.com]
Sent: 03 December, 2002 23:20
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Luby | 12 Dec 2002 23:36
Favicon

WEBRC 04 draft

RMT WG,
The just published -04 version of the WEBRC draft is not substantially
different than the -03 version, consisting of some minor clarifications,
text fixes and reference updates.  I would love to see this move to working
group last call, moving it towards an Experimental RFC.
Mike
Permalink | Reply | 0 comments |
headers
Lorenzo Vicisano | 20 Dec 2002 03:26
Picon
Favicon

WG last call for draft-ietf-rmt-bb-webrc-04.txt

Dear RMT-ers,

We would like to start a working group last call for
draft-ietf-rmt-bb-webrc-04.txt ending Friday January 10th 2003 (little
extra time given the vacations).

Please note that this will be our fist submission of a congestion
control BB as an experimental RFC. At the last IETF meeting we thought
that the WEBRC congestion scheme had undergone enough study and
experimentation to go ahead, but we also decided that we would have
asked the opinion of this mailing list. Hence you are also invited to
comment on this matter.

	thank you,
	the chairs.
Permalink | Reply | 0 comments |
headers
rfc-editor | 24 Dec 2002 20:00
Favicon

RFC 3450 on Asynchronous Layered Coding (ALC) Protocol Instantiation


A new Request for Comments is now available in online RFC libraries.

        RFC 3450

        Title:      Asynchronous Layered Coding (ALC) Protocol
                    Instantiation
        Author(s):  M. Luby, J. Gemmell, L. Vicisano, L. Rizzo,
                    J. Crowcroft
        Status:     Experimental
        Date:       December 2002
        Mailbox:    luby <at> digitalfountain.com, jgemmell <at> microsoft.com,
                    lorenzo <at> cisco.com, luigi <at> iet.unipi.it,
                    Jon.Crowcroft <at> cl.cam.ac.uk
        Pages:      34
        Characters: 86022
        Updates/Obsoletes/See Also:   None

        I-D Tag:    draft-ietf-rmt-pi-alc-08.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3450.txt

This document describes the Asynchronous Layered Coding (ALC)
protocol, a massively scalable reliable content delivery protocol.
Asynchronous Layered Coding combines the Layered Coding Transport
(LCT) building block, a multiple rate congestion control building
block and the Forward Error Correction (FEC) building block to provide
congestion controlled reliable asynchronous delivery of content to an
unlimited number of concurrent receivers from a single sender.
(Continue reading)

Permalink | Reply | 0 comments |
headers
rfc-editor | 24 Dec 2002 20:01
Favicon

RFC 3451 on Layered Coding Transport (LCT) Building Block


A new Request for Comments is now available in online RFC libraries.

        RFC 3451

        Title:      Layered Coding Transport (LCT) Building Block
        Author(s):  M. Luby, J. Gemmell, L. Vicisano, L. Rizzo,
                    M. Handley, J. Crowcroft
        Status:     Experimental
        Date:       December 2002
        Mailbox:    luby <at> digitalfountain.com, jgemmell <at> microsoft.com,
                    lorenzo <at> cisco.com, luigi <at> iet.unipi.it,
                    mjh <at> aciri.org, Jon.Crowcroft <at> cl.cam.ac.uk
        Pages:      29
        Characters: 72594
        Updates/Obsoletes/See Also:   None

        I-D Tag:    draft-ietf-rmt-bb-fec-lct-04.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3451.txt

Layered Coding Transport (LCT) provides transport level
support for reliable content delivery and stream delivery
protocols.  LCT is specifically designed to support protocols
using IP multicast, but also provides support to protocols
that use unicast.  LCT is compatible with congestion control
that provides multiple rate delivery to receivers and is also
compatible with coding techniques that provide reliable
delivery of content.
(Continue reading)

Permalink | Reply | 0 comments |
headers
rfc-editor | 24 Dec 2002 20:04
Favicon

RFC 3452 on Forward Error Correction (FEC) Building Block


A new Request for Comments is now available in online RFC libraries.

        RFC 3452

        Title:      Forward Error Correction Building Block
        Author(s):  M. Luby, L. Vicisano, J. Gemmell, L. Rizzo,
                    M. Handley, J. Crowcroft
        Status:     Experimental
        Date:       December 2002
        Mailbox:    luby <at> digitalfountain.com, lorenzo <at> cisco.com,
                    jgemmell <at> microsoft.com, luigi <at> iet.unipi.it,
                    mjh <at> aciri.org, Jon.Crowcroft <at> cl.cam.ac.uk
        Pages:      16
        Characters: 38368
        Updates/Obsoletes/See Also:   None

        I-D Tag:    draft-ietf-rmt-bb-fec-07.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3452.txt

This document generally describes how to use Forward Error Correction
(FEC) codes to efficiently provide and/or augment reliability for data
transport.  The primary focus of this document is the application of
FEC codes to one-to-many reliable data transport using IP
multicast.  This document describes what information is needed to
identify a specific FEC code, what information needs to be
communicated out-of-band to use the FEC code, and what information is
needed in data packets to identify the encoding symbols they carry.
The procedures for specifying FEC codes and registering them with the
(Continue reading)

Permalink | Reply | 0 comments |
headers
rfc-editor | 24 Dec 2002 20:06
Favicon

RFC 3453 on The Use of Forward Error Correction (FEC) in Reliable Multicast


A new Request for Comments is now available in online RFC libraries.

        RFC 3453

        Title:      The Use of Forward Error Correction in Reliable
                    Multicast
        Author(s):  M. Luby, L. Vicisano, J. Gemmell, L. Rizzo,
                    M. Handley, J. Crowcroft
        Status:     Informational
        Date:       December 2002
        Mailbox:    luby <at> digitalfountain.com, lorenzo <at> cisco.com,
                    jgemmell <at> microsoft.com, luigi <at> iet.unipi.it,
                    mjh <at> aciri.org, Jon.Crowcroft <at> cl.cam.ac.uk
        Pages:      18
        Characters: 46853
        Updates/Obsoletes/See Also:   None

        I-D Tag:    draft-ietf-rmt-info-fec-03.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3453.txt

This memo describes the use of Forward Error Correction (FEC) codes to
efficiently provide and/or augment reliability for one-to-many
reliable data transport using IP multicast.  One of the key properties
of FEC codes in this context is the ability to use the same packets
containing FEC data to simultaneously repair different packet loss
patterns at multiple receivers.  Different classes of FEC codes and
some of their basic properties are described and terminology relevant
to implementing FEC in a reliable multicast protocol is introduced.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane