Internet DRAFT - draft-franceschini-avt-bwmetrics
draft-franceschini-avt-bwmetrics
avt G. Franceschini
Internet Draft Telecom Italia Lab
Expires: August 2007 February 13, 2007
Bandwidth Metrics
draft-franceschini-avt-bwmetrics-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on August 13, 2007.
Franceschini Expires August 13, 2007 [Page 1]
Internet-Draft Bandwidth Metrics February 2007
Abstract
When delivering audio and video data through low capacity links, it
is important to optimally exploit the limited resources in order to
provide the best possible user experience. QoS aspects in this
respect might relate to the pure audio and video quality, as well as
to delay and lip-sync. The actual weights of the different QoS
aspects depend on the service being offered, and are out of the scope
of this document.
In order to optimally exploit the limited resources, it is necessary
to get a reasonable precise measurement of them. This document
proposes metrics to address this problem.
This document, in this initial draft, focuses only on the semantic
aspects, leaving out the syntactical details.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [1].
Franceschini Expires August 13, 2007 [Page 2]
Internet-Draft Bandwidth Metrics February 2007
Table of Contents
1. Introduction...................................................4
2. The starting point.............................................5
2.1. Use case: peer-to-peer audio/visual narrowband communication
...............................................................5
2.2. The proposed metrics......................................5
2.3. Examples of metrics values................................7
2.3.1. PSTN stack including RTP/UDP/IP/PPP/LAPM, with 40 Kbit/s
of physical capacity........................................7
2.3.2. ATM stack including RTP/UDP/IP/PPP/ETH+FCS/LLC-
SNAP/AAL5/ATM, with 128 Kbit/s of physical capacity.........9
2.4. Sender decisions affecting QoS...........................10
2.5. Computation of the optimal transmission parameters.......11
2.5.1. Parameters..........................................11
2.5.2. Computation of MaxVSize.............................12
2.5.3. Computation of MaxPTime.............................12
2.5.4. Computation of VideoBW..............................14
2.6. Examples of use..........................................15
3. Other issues..................................................18
3.1. Narrowband and wideband communication....................18
3.2. Session level and media level parameters.................18
3.3. Point-to-point and point-to-multipoint...................19
3.4. TIDC or MPO updates......................................19
3.5. RTCP support.............................................20
3.6. Middle boxes.............................................20
4. Security Considerations.......................................21
5. IANA Considerations...........................................21
6. Conclusions...................................................21
7. Acknowledgments...............................................21
8. References....................................................22
8.1. Normative References.....................................22
8.2. Informative References...................................22
Author's Addresses...............................................22
Intellectual Property Statement..................................22
Disclaimer of Validity...........................................23
Copyright Statement..............................................23
Acknowledgment...................................................23
Franceschini Expires August 13, 2007 [Page 3]
Internet-Draft Bandwidth Metrics February 2007
1. Introduction
In a path from A to B, there are often one or more bottlenecks that
limit the bandwidth available for the audio and/or video data.
Bottlenecks can, in principle, be present in any link, but most
reasonably they are present at the access links of A and/or B. When
this occurs, knowledge about the characteristics of such
bottleneck(s) is essential to:
i) prevent congestion;
ii) exploit the available resources at their maximum capacity.
The requirement of defining metrics that precisely characterize the
bottleneck capacity applies to both the initial negotiation phase and
to the case of updates.
It is well known that the simple indication of a bandwidth value
(such as the CT or AS bandwidth parameters) provides quite vague
information, since the protocol stack overhead remains unknown, and
might greatly affect the overall bandwidth consumption. As a
consequence, a compromise between the requirements (i) and (ii) above
is chosen in a conservative way, that sacrifices (ii) to make (i)
almost guaranteed. Sometimes this compromise results in an excess of
unnecessary sacrifice for (ii).
The indication of a couple of values (one being some form of
bandwidth, and one being some indication of overhead) looks
definitely more attractive, and has the potential of reducing the
vagueness in the information, thus allowing for a less severe
sacrifice in (ii).
Also, since links might not necessarily present the same
characteristics in Uplink and Downlink, the information shall relate
to a specific direction.
This document presents in section 2 a first use-case (peer-to-peer
audio/visual narrowband communication), proposes new bandwidth
metrics and shows how this use-case would benefit from the signaling
of such metrics. Subsections 2.1 through 2.3 are the most relevant,
while 2.4 through 2.6 are dedicated to those really intrigued in the
algorithm.
More sceanrios and issues are then considered in section 3, along
with proposed solutions that both address variations to the original
proposal of section 2, and highlights potential further areas of
work.
Franceschini Expires August 13, 2007 [Page 4]
Internet-Draft Bandwidth Metrics February 2007
2. The starting point
2.1. Use case: peer-to-peer audio/visual narrowband communication
The whole work presented in this document derives from the analysis,
implementation and deployment experience conducted on a well-defined
use case: peer-to-peer audio/visual narrowband communication.
For such a scenario the basic requirement was very simple: optimize
the user experience!
2.2. The proposed metrics
When audio/video data is delivered through an IP Network, a number of
protocol layers are involved, resulting in a significant overhead.
The protocol stack typically involves, from the application layer
down to the physical medium:
o the Real-time Transport Protocol (RTP);
o the User Datagram Protocol (UDP);
o the Internet Protocol (IP);
o a number of different protocol stacks featuring Data Link and
Physical Layer functionalities and that depend on the specific
network itself.
The overhead induced by the RTP/UDP/IP protocol layers might, in some
case, differ significantly from the normal 40 bytes. E.g., IP
Tunneling could be employed, that implies a sort of "double" IP
layer, and in essence an extra overhead for each packet. Another
technique used in some context is the compression of the RTP/UDP/IP
headers. Other changes in the overhead might derive from the usage of
IP-SEC or of IPv6, and possibly from other variations in the stack
currently not envisaged.
The computation of the overhead induced by the protocol layers below
the IP level is even more complex.
On some networks, data is physically streamed according to a framing
mechanism totally decoupled from the IP packetization; in other
cases, the IP packets boundaries are preserved, but adapted with
extra padding to fit the physical frames.
The overhead due to the various protocol layers can be in general
modeled as:
Franceschini Expires August 13, 2007 [Page 5]
Internet-Draft Bandwidth Metrics February 2007
o per packet overhead, when the protocol layer takes care of the
packet boundaries of the upper layer, and adds a certain overhead
on each such data packet: the bigger the data packet is, the lower
the overhead percentage results (examples are RTP, UDP, IP, as
well as ETH, PPP)
o per byte overhead, when the protocol layer ignores the packet
boundaries of the upper layer, and manages the data traffic as a
stream of bytes to which it adds a certain mean overhead; e.g.:
o the stream of bytes is segmented in frames of a certain
length, each having a header and/or trailer (e.g.: LAP-M);
o the stream of bytes is coded according to some rule, e.g.
escape bytes are inserted to avoid emulating certain
sequences, whose occurrence can be statistically determined
(e.g.: again LAP-M);
all such examples can be modeled as a fixed overhead percentage;
o stepwise overhead, when the protocol layer takes care of the
packet boundaries of the upper layer, but encapsulates the upper
layer data in frames of fixed length, adding padding bytes to fill
the last frame assigned to the upper layer packet: this is the
case of e.g. ATM-AAL5, where an upper layer data packet is
segmented to fit the payload space of an integral number of ATM
cells, with padding in the last cell of 0 to 47 bytes; this is the
most difficult case to model, since the difference of 1 byte in
the packet length at the application layer might result in a full
additional ATM cell (53 bytes). In practice, it sounds reasonable
in such a case to compute a statistically equivalent per-byte
overhead.
Thus, in general, the computation of the overhead induced by the
various protocol layers on an audio or video flow is not trivial, and
definitely depends on how big the packets generated at the
application layer are, and how these packets are managed through the
different protocol layers.
Since the overhead depends on the protocol stack, it can potentially
change on each link of the delivery path. The most important overhead
is clearly the overhead associated to the bottleneck link.
In a path from A to B, assuming that the two potential bottlenecks
are the links close to peer A and peer B themselves, the sender (A)
needs information about the characteristics of the local UplinkA and
of the remote DownlinkB. Once such characterization is available at
Franceschini Expires August 13, 2007 [Page 6]
Internet-Draft Bandwidth Metrics February 2007
sender A, it might identify the best compromises between e2e delay
and overhead, and determine the values for the maxptime, maxvsize and
videobw parameters defined above: in essence, sender A will be able
to make its own best decision on how to (i) prevent congestion and at
the same time (ii) exploit the available resources at their maximum
capacity.
The proposed metrics measure the bandwidth available at a certain
protocol stack layer and the corresponding mean per-packet overhead:
o TIDC/TIUC (Transport Independent Downlink/Uplink Capacity):
represents the capacity (in Kbit/s) of the link
(Downstream/Upstream direction) measured at a certain protocol
stack layer.
o MPO (Mean Packet Overhead): represents the mean overhead that
applies to each packet from the layer above RTP down to the
protocol stack layer at which the corresponding TIxC value has
been measured. The overhead excludes any bytes in excess with
respect to the canonical 12 bytes RTP header. Thus RTP Header
extensions are not included, and neither are the Payload Format
overheads.
2.3. Examples of metrics values
2.3.1. PSTN stack including RTP/UDP/IP/PPP/LAPM, with 40 Kbit/s of
physical capacity.
The contribution of the various layers to the per-packet overhead is:
RTP (12), UDP (8), IP (20), PPP (8); in addition the LAPM provides a
per-byte overhead of about 10% (this figure depends on some parameter
of the LAPM itself, but for the example purposes let's assume 10%).
This means that 40 - 10% = 36 Kbit/s are left to the PPP layer. Also,
the total per-packet overhead at the PPP layer is 12+8+20+8 = 48
bytes
For such a case an optimal tuple would therefore be:
TIDC(PPP) = 36
MPOD(PPP) = 48
The above tuple refers to the PPP layer. If the IP layer were
selected instead, the MPO figure would clearly decrease to 40.
However, it is not obvious how to compute the TIDC for the IP layer,
since the PPP layer provides a per-packet overhead, not a per-byte
overhead. Thus, an hypothesis on the packet rate is required, say 50
Franceschini Expires August 13, 2007 [Page 7]
Internet-Draft Bandwidth Metrics February 2007
packets/second. This translates into 3200 bit/sec of overhead, i.e.
~3 Kbit/s. The tuple therefore becomes:
TIDC(IP,50) = 33
MPOD(IP) = 40
This tuple relative to the IP layer however implies as well a packet
rate of 50 packets/sec, whereas the tuple relative to the PPP layer
had no assumption on the packet rate.
Using the same approach and hypothesis of 50 packets/sec, the tuples
relative to the UDP, RTP and application layer can be computed as
well:
TIDC(UDP,50) = 25
MPOD(UDP) = 20
TIDC(RTP,50) = 22
MPOD(RTP) = 12
TIDC(APP,50) = 17
MPOD(APP) = 0
All five tuples are equivalent as far as the hypothesis of 50
packets/sec is correct. But the more the reality diverges from the
hypothesis, the more the APP, RTP, UDP and IP tuples provide
inaccurate information, while the PPP tuple remains correct, since it
is independent on the packet rate assumption.
In other words, if the measurement is made at the interface between
the lowest protocol stack layer providing per-packet overhead and the
highest protocol stack layer providing per-byte overhead, that
measurement is accurate under all packet rates. Otherwise, it is only
precise when the packet rate hypothesis well approximates the
reality.
Indeed, if the packet rate hypothesis changes into 25 packets/sec the
new figures become:
TIDC(IP,25) = 34
MPOD(IP) = 40
TIDC(UDP,25) = 30
MPOD(UDP) = 20
TIDC(RTP,25) = 29
MPOD(RTP) = 12
TIDC(APP,25) = 26
Franceschini Expires August 13, 2007 [Page 8]
Internet-Draft Bandwidth Metrics February 2007
MPOD(APP) = 0
2.3.2. ATM stack including RTP/UDP/IP/PPP/ETH+FCS/LLC-SNAP/AAL5/ATM,
with 128 Kbit/s of physical capacity.
The contribution of the various layers to the per-packet overhead is:
RTP (12), UDP (8), IP (20), PPP (8), ETH+FCS (18), LLC/SNAP (10),
AAL5 (8); in addition the ATM layer provides a fixed per-byte
overhead of about 10% (5 header bytes for every 48 payload bytes)
plus a statistical per-byte overhead of, say, another 10% (due to the
padding of 0-47 bytes in the last cell belonging to an AAL5 PDU).
This means that 128 - 20% = 102 Kbit/s are left to the AAL5 layer.
Also, the total per-packet overhead at the AAL5 layer is
12+8+20+8+18+10+8 = 84 bytes
For such a case an optimal tuple would therefore be:
TIDC(AAL5) = 102
MPOD(AAL5) = 84
As in the previous example, here as well it is possible to compute
alternate tuples based on an hypothesis on the packet rate. Say,
again, 50 packet/sec. We can then obtain:
TIDC(IP,50) = 84
MPOD(IP) = 40
TIDC(UDP,50) = 76
MPOD(UDP) = 20
TIDC(RTP,50) = 73
MPOD(RTP) = 12
TIDC(APP,50) = 68
MPOD(APP) = 0
While for 25 packets/sec the figures become:
TIDC(IP,25) = 93
MPOD(IP) = 40
TIDC(UDP,25) = 89
MPOD(UDP) = 20
TIDC(RTP,25) = 88
MPOD(RTP) = 12
Franceschini Expires August 13, 2007 [Page 9]
Internet-Draft Bandwidth Metrics February 2007
TIDC(APP,25) = 85
MPOD(APP) = 0
2.4. Sender decisions affecting QoS
For the peer-to-peer audio/visual narrowband communication scenario,
three encoding and transmission parameters have been identified as
crucial for the overall QoS, and mostly determined by a sender-only
decision:
o maxptime: maximum length (in ms) of the audio content transmitted
in a single audio RTP packet;
o maxvsize: maximum length (in bytes) of a video RTP packet;
o videobw: bandwidth assigned to the video stream at the media
level.
These parameters affect the QoS because:
maxptime: small values imply low acquisition, serialization and
rendering delays, thus an overall low e2e delay. On the other hand,
the generation of many small RTP packets determines a significantly
high transmission overhead that erodes the bandwidth available for
the video stream. This might be less evident when RTP Header
compression techniques are in place. In general, the sender shall
identify an acceptable compromise between e2e delay and overhead,
although there are cases where the value is quite constrained.
maxvsize: small values allow for a fine interleaving between audio
and video packets, thus keep low the amount of jitter induced on the
audio delivery by the serialization of the video RTP packets. Such a
jitter directly contributes to the audio e2e delay. On the other
hand, the generation of many small RTP packets determines a
significantly high transmission overhead that erodes the bandwidth
available for the video stream. Here again the sender shall identify
an acceptable compromise between audio e2e delay and overhead. There
is of course an upper-bound constraint that is determined by the path
MTU-SIZE.
videobw: small values allow for a conservative approach in which the
path capacity is under-utilized, therefore preventing congestion in
case of transient problems (e.g. retransmissions). On the other hand,
the video quality is directly proportional to the video bandwidth.
The sender shall identify the highest possible value that still keeps
the risk of congestion acceptable.
Franceschini Expires August 13, 2007 [Page 10]
Internet-Draft Bandwidth Metrics February 2007
Of course many other parameters could be considered, such as the
audio bandwidth itself (e.g.: AMR coding can range from 4.75 up to
12.2 Kbit/s), but it is believed that the three parameters above are
the ones that deserve the main attention.
2.5. Computation of the optimal transmission parameters
2.5.1. Parameters
Here is a possible algorithm for computing the optimal transmission
parameters. Here a number of constraints are set: this is an example,
and the mechanism by which the sender is made aware of the values of
such constraints is outside the scope of this document.
The parameters to compute are:
o MaxPTime: maximum length (in ms) of the audio content transmitted
in a single audio RTP packet;
o MaxVSize: maximum length (in bytes) of a video RTP packet;
o VideoBW: bandwidth assigned to the video stream at the media
level.
The parameters providing the link characterization are:
o TIDC: the remote Downlink capacity in bit/s
o MPOD: the remote Downlink mean packet overhead in Bytes
o TIUC: the local Uplink capacity in bit/s
o MPOU: the local Uplink mean packet overhead in Bytes
In the following they will be often referred to as TIxC and MPOx, to
mean either remote Downlink or local Uplink.
Furthermore, the following constraints are set:
o MTUSIZE: maximum IP packet length;
o MAX_JITTER_INT: maximum interleaving jitter (in ms), computed as
the difference between the minimal and maximum delay of an audio
packet due to the interleaving of video packets;
o MIN_VIDEO_BW: the minimum bandwidth to dedicate to the video
stream at the media level;
o AUDIO_BW: the bandwidth to dedicate to the audio stream at the
media level;
Franceschini Expires August 13, 2007 [Page 11]
Internet-Draft Bandwidth Metrics February 2007
o MAX_AUDIOLENMS: the maximum value for MaxPTime.
o MIN_AUDIOLENMS: the minimum value for MaxPTime.
o AUDIOFRAMELENMS: the audio frame length.
2.5.2. Computation of MaxVSize
This parameter shall assume the highest possible value (to reduce
overhead) coherently with the following constraints:
o Shall be small enough to avoid causing an interleaving jitter
greater than MAX_JITTER_INT;
o Shall be small enough to avoid causing IP fragmentation
(coherently with MTUSIZE).
The minimum delay of an audio packet induced by the interleaving of
video packets is clearly 0. The interleaving jitter thus equates the
maximum delay of an audio packet induced by the interleaving of video
packets. This in turn can be reasonably computed as the serialization
time of the longest video packet across the two known links (UplinkA
and DownlinkB). Thus (all terms in bytes, ms and bits/ms):
MAX_JITTER_INT = ((MaxVSize+MPOD)*8/TIDC + (MaxVSize+MPOU)*8/TIUC)
Assuming that MAX_JITTER_INT is known (constraint), and that MPOD,
TIDC, MPOU e TIUC are known as well, it is possible to obtain
MaxVSize:
MaxVSize = [(MAX_JITTER_INT * TIDC * TIUC / 8) - (MPOD * TIUC) -
(MPOU * TIDC)] / (TIUC + TIDC)
If no audio is involved, MaxVSize does not require -of course- any
such calculation.
MaxVSize shall than respect the IP requirement of not causing any IP
fragmentation, and (notwithstanding all possible variations of the
RTP/UDP/IP stack) a typical formula would just be:
MaxVSize <= MTUSIZE - 40
2.5.3. Computation of MaxPTime
This parameter shall assume the lowest possible value (to reduce e2e
delay) coherently with the following constraints:
o It shall correspond to an integral multiple of the AUDIOFRAMELENMS
(e.g. Nx10 ms for G.729, or Nx20 ms for AMR)
Franceschini Expires August 13, 2007 [Page 12]
Internet-Draft Bandwidth Metrics February 2007
o Shall not be bigger than MAX_AUDIOLENMS
o Shall not be smaller than MAX_AUDIOLENMS
o Shall be big enough to not erode excessive bandwidth to the video
payload, which is requested to reach at least MIN_VIDEO_BW;
The available bandwidth (TIUC or TIDC) can be assigned to audio and
video payload and overhead as in the formula below:
TIxC >= BW_V + BW_A + OVx_V + OVx_A
Where:
o BW_V is the pure video bandwidth, which is required to be >
MIN_VIDEO_BW
o BW_A is the pure audio bandwidth, which is known to be AUDIO_BW
o OVx_V and OVx_A are the bandwidths consumed by the overheads for
audio and video
By 'x' is meant either 'D' (remote Downlink) or 'U'(local Uplink).
The OVx_V can be approximated, being known the MaxVSize, as a
function of BW_V (all terms in bytes, ms and bits/ms):
OVx_V = <video packet rate> * MPOx * 8
OVx_V = (BW_V/((MaxVSize+MPOx)*8)) * MPOx * 8
And being MIN_VIDEO_BW the target for BW_V:
OVx_V = (MIN_VIDEO_BW/((MaxVSize+MPOx)*8)) * MPOx * 8
The OVx_A can be represented as a function of MaxPTime:
OVx_A = (1000/MaxPTime) * MPOx * 8
From:
TIxC >= BW_V + BW_A + OVx_V + OVx_A
We get:
OVx_A <= TIxC - BW_V - BW_A - OVx_V
The formula (for both the local Uplink and remote Downlink) now
contains on the right side all known terms. Thus the upper limit for
OVx_A can be computed for both the local Uplink and remote Downlink.
Franceschini Expires August 13, 2007 [Page 13]
Internet-Draft Bandwidth Metrics February 2007
Thus, it is possible to derive the lower limit for MaxPTime(x) (all
terms in bytes, ms and bits/ms):
MaxPTime(x) >= MPOx * 8 / OVx_A
Which corresponds to:
MaxPTime(x) >= (MPOx * 8) / (TIxC - MIN_VIDEO_BW - BW_A -
((MIN_VIDEO_BW/((MaxVSize + MPOx) * 8 )) * MPOx * 8))
End finally determine:
MaxPTime >= max (MaxPTime(D), MaxPTime(U))
This lower limit will be then round up to fit an integral number of
audio frames.
If this result is outside the boundaries set by the MIN_AUDIOLENMS
and MAX_AUDIOLENMS, then of course the MaxPTime shall be corrected
accordingly: this would mean however that it is not possible to
guarantee the MIN_VIDEO_BW to the video payload.
In case the upper limit for OVx_A is negative, and thus a MaxPTime(x)
is also negative, that means that there is not enough bandwidth to
accommodate the constraints: in such a case the best compromise is to
set MaxPTime to the maximum acceptable, to leave as much bandwidth as
possible to the video. In case MaxPTime(x) becomes negative, that
means that there is not enough.
2.5.4. Computation of VideoBW
This parameter shall assume the highest possible value (to reduce
overhead)
Starting again from:
TIxC >= BW_V + BW_A + OVx_V + OVx_A
And being now known the OVx_A contribution, it is possible to
identify the upper limit for BW_V.
OVx_A = (MPOx * 8) / MaxPTime
BW_V + OVx_V <= TIxC - BW_A - OVx_A
And replacing the OVx_V term:
BW_V * (1 + (1/((MaxVSize+MPOx)*8)) * MPOx * 8) <= TIxC - BW_A -
OVx_A
Franceschini Expires August 13, 2007 [Page 14]
Internet-Draft Bandwidth Metrics February 2007
All terms are known, thus for both the local Uplink and remote
Downlink it is possible to determine the upper limit for BW_V(x).
VideoBW(x) <= (TIxC-BW_A-((MPOx*8) / MaxPTime))
/(1+(1/((MaxVSize+MPOx)*8))*MPOx*8)
And finally identify the maximum value that fits both:
VideoBW = min (VideoBW(D), VideoBW(U))
2.6. Examples of use
Suppose the audio/video communication scenario involves peers A and
B, with peer A on a PSTN link and peer B on a ATM link, running the
protocol stack as described in the above examples.
Assume the TIxC/MPOx values are the following:
At link A (PSTN line with a line rate of 40 Kbit/s Downlink and 33
Kbit/s Uplink):
o TIDC(PPP) = 36
o MPOD(PPP) = 48
o TIUC(PPP) = 30
o MPOU(PPP) = 48
At link B (ATM link at 128 Kbit/s in both directions)
o TIDC(AAL5) = 102
o MPOD(AAL5) = 84
o TIUC(AAL5) = 102
o MPOU(AAL5) = 84
Also assume that the constraints are set to:
o MTUSIZE: 1500 bytes
o MAX_JITTER_INT: 150 ms
o MIN_VIDEO_BW: 20 Kbit/s
o AUDIO_BW: 8 Kbit/s
Franceschini Expires August 13, 2007 [Page 15]
Internet-Draft Bandwidth Metrics February 2007
o MAX_AUDIOLENMS: 120 ms
o MIN_AUDIOLENMS: 20 ms
o AUDIOFRAMELENMS: 20 ms
Applying the formulas above in the A=>B direction:
MaxVSize = ((MAX_JITTER_INT * TIDC * TIUC / 8) - (MPOD * TIUC) -
(MPOU * TIDC)) / (TIUC + TIDC)
= ((150 * 102 * 30 / 8) - (84 * 30) - (48 * 102)) / (30+102)
= 378 bytes
MaxPTime(D) >= (MPOD * 8) / (TIDC - MIN_VIDEO_BW - BW_A -
((MIN_VIDEO_BW / ((MaxVSize + MPOD) * 8)) * MPOD * 8))
= (84 * 8) / (102 - 20 - 8 - ((20 / ((378 + 84) * 8)) * 84 * 8))
= 10 ms
MaxPTime(U) >= (MPOU * 8) / (TIUC - MIN_VIDEO_BW - BW_A -
((MIN_VIDEO_BW / ((MaxVSize + MPOU) * 8)) * MPOU * 8))
= (48 * 8) / (30 - 20 - 8 - ((20 / ((378 + 48) * 8)) * 48 * 8))
= -1514 ms
Being MaxPTime(U) negative:
MaxPTime = MAX_AUDIOLENMS = 120 ms
VideoBW(D) <= (TIDC-BW_A-((MPOD * 8) / MaxPTime)) / (1 + (1 /
((MaxVSize + MPOD) * 8)) * MPOD * 8)
= (102 - 8 - ((84 * 8) / 120)) / (1 + (1 / ((378 + 84) * 8)) * 84 *8)
= 74 Kbit/s
VideoBW(U) <= (TIUC - BW_A - ((MPOU * 8) / MaxPTime)) / (1 + (1 /
((MaxVSize + MPOU) * 8)) * MPOU * 8)
= (30 - 8 - ((48 * 8) / 120)) / (1 + (1 / ((378 + 48) * 8)) * 48 * 8)
= 16 Kbit/s
Thus
VideoBW = 16 Kbit/s
(which is indeed lower than the constraint MIN_VIDEO_BW)
Applying the formulas above in the B=>A direction:
MaxVSize = ((MAX_JITTER_INT * TIDC * TIUC / 8) - (MPOD * TIUC) -
(MPOU * TIDC)) / (TIUC + TIDC)
Franceschini Expires August 13, 2007 [Page 16]
Internet-Draft Bandwidth Metrics February 2007
= ((150 * 36 * 102 / 8) - (48 * 102) - (84 * 36)) / (102 + 36)
= 441 bytes
MaxPTime(D) >= (MPOD * 8) / (TIDC - MIN_VIDEO_BW - BW_A -
((MIN_VIDEO_BW / ((MaxVSize + MPOD) * 8 )) * MPOD * 8))
= (48 * 8) / (36 - 20 - 8 - ((20 / ((441 + 48) * 8)) * 48 * 8))
= 64 ms
MaxPTime(U) >= (MPOU * 8) / (TIUC - MIN_VIDEO_BW - BW_A -
((MIN_VIDEO_BW / ((MaxVSize + MPOU) * 8 )) * MPOU * 8))
= (84 * 8) / (102 - 20 - 8 - ((20 / ((441 + 84) * 8)) * 84 * 8))
= 10 ms
MaxPTime >= max (MaxPTime(D), MaxPTime(U))
Being AUDIOFRAMELENMS = 20 ms:
MaxPTime = 80 ms
VideoBW(D) <= (TIDC - BW_A - ((MPOD * 8) / MaxPTime)) / (1 + (1 /
((MaxVSize + MPOD) * 8)) * MPOD * 8)
= (36 - 8 - ((48 * 8) / 80)) / (1 + (1 / ((441 + 48) * 8)) * 48 * 8)
= 21 Kbit/s
VideoBW(U) <= (TIUC - BW_A - ((MPOU * 8) / MaxPTime)) / (1 + (1 /
((MaxVSize + MPOU) * 8)) * MPOU * 8)
= (102 - 8 - ((84 * 8) / 80)) / (1 + (1 / ((441 + 84) * 8)) * 84 * 8)
= 73 Kbit/s
Thus
VideoBW = 21 Kbit/s
(which is indeed higher than the constraint MIN_VIDEO_BW)
Thus, in this example peer A will use:
o MaxVSize = 378 bytes
o MaxPTime = 120 ms
o VideoBW = 16 Kbit/s
And peer B will use:
o MaxVSize = 441 bytes
o MaxPTime = 80 ms
Franceschini Expires August 13, 2007 [Page 17]
Internet-Draft Bandwidth Metrics February 2007
o VideoBW = 21 Kbit/s
3. Other issues
3.1. Narrowband and wideband communication
The algorithm presented in section 2, which is based on the exchange
of downlink capacity characterization, aims at saturating the
bottleneck's capacity. This is not necessarily desired. Suppose,
e.g., that both peers A and B in a video communication session happen
to reside on a wideband link: in such a case an upper (at least
approximate) limit for the bandwidth to dedicate to the communication
session shall be set.
Thus, when a terminal attached to a wideband link is involved in a
communication session (as peer A), it makes little sense for that
terminal to communicate its TIDC and MPO values. However, if it does
not communicate such values, then peer B would not be aware of the
ability of peer A to interpret such TIDC and MPO parameters.
A different, preferable solution could therefore consist in having
peer A communicating in addition to its TIDC and MPO values, a
further parameter that specifies an approximate upper bandwidth limit
for the communication session. The CT parameter as already defined in
RFC3550 seems appropriate for this goal, or anyway an ad-hoc
parameter could be defined if CT is deemed inapplicable.
3.2. Session level and media level parameters
The algorithm presented in section 2 implies that TIDC is a session
level parameter. The usage of TIDC as session level parameter allows
taking care of the cross-media relations, and more specifically of:
o the impact of video packet sizes on audio jitter, in case audio
and video RTP packets get serialized on the physical link;
o the impact of audio packet rate (and thus overhead) on the
bandwidth that remains available for the video.
The usage of TIDC as media level parameter would sacrifice the above
advantages; furthermore, the application would be responsible of
segmenting the overall available bandwidth between video and audio,
leading to a potential sub-optimization in case the goal is to
saturate the bottleneck.
There might be however scenarios in which such cons are not relevant,
and where therefore the TIDC as media level parameter could be
acceptable.
Franceschini Expires August 13, 2007 [Page 18]
Internet-Draft Bandwidth Metrics February 2007
Concerning the MPO parameter instead, it better fits with a media
level definition, since in cases where header compression techniques
are in place, their effectiveness might result quite different for
audio and video. When no difference in MPO for audio and video
exists, it is questionable whether to exchange a single session level
value, or keep exchanging two individual media level values.
3.3. Point-to-point and point-to-multipoint
The algorithm presented in section 2 has been conceived for a point-
to-point scenario, and naturally fits the SDP capability exchange
model that takes place during a SIP session setup. Thus, the TIDC and
MPO parameters could be exchanged between the peers by means of
simple additions to the set of SDP parameters.
In point-to-multipoint scenarios instead, the SIP signaling protocol
is not used, and the capability information flows only from source to
destination. In order to let the destination(s) communicate their own
capabilities back to the source, no specific mechanism is generally
used other than RTCP.
This implies that in order to apply the proposed algorithm in point-
to-multipoint scenarios as well, appropriate RTCP messages carrying
the relevant information (TIDC, MPO) should be defined.
3.4. TIDC or MPO updates
During the lifetime of a communication session, the TIDC (and maybe
MPO) parameters originally communicated could change. This is true,
for example, in PSTN modems, that might re-negotiate the physical
bandwidth as a result of excessive error-rate; and of course this
happens as well in mobile links.
When working in a SIP based, peer-to-peer communication session, the
REINVITE method could be exploited to communicate such an update.
There are different opinions on the applicability of this solution,
but this is certainly a potential candidate solution.
A different mechanism could be based on providing feedback via RTCP:
such a solution would be synergic with the extension of applicability
to point-to-multipoint sessions.
Thus, while implementing the REINVITE would solve the update issue
(with a number of cons) but would not providing any advantage towards
the point-to-multipoint scenario, the definition of appropriate RTCP
messages would address both issues.
Franceschini Expires August 13, 2007 [Page 19]
Internet-Draft Bandwidth Metrics February 2007
3.5. RTCP support
The definition of appropriate RTCP messages to update the TIDC and/or
MPO values highly depends on whether such parameters are at session
or at media level. In the latter case, there is no conceptual
obstacle, and indeed the TMMBR messages being defined in AVT are
exactly addressing this kind of problem (i.e. signal a change in the
channel capacity).
If instead the TIDC parameter is kept in its session level meaning,
then a different kind of extension to RTCP feedback mechanisms is
required, since there is no current provision in RTCP to provide
feedback on session level parameters.
The issues here are not of syntactic nature, since RTCP already
includes elements that have session level scope (e.g.: in SDES or
APP), which could be easily extended to carry TIDC information; the
problem instead is of coherence with the general RTCP architectural
design, a field in which the author does not feel expert enough to
autonomously provide any assertion.
3.6. Middle boxes
Presence of middle boxes along the path between a sender A and a
receiver B needs special care.
As far as a SIP INVITE or REINVITE is considered, middle boxes might
be given the right to inspect and alter the SDP description. This
might be meaningful in case the middle box knows about a bottleneck
that is not otherwise known at the peers A and B: in such a case the
middle box could add the characterization of such bottleneck in the
SDP descriptions, and the recipient of such SDP could therefore get
information about more than one potential bottleneck. The algorithm
presented in section 2 could be easily updated to deal with multiple
bottlenecks.
As far as RTCP feedback messages are concerned, it is conceivable
that a middle box re-generates RTCP messages and that in doing so, it
also inserts subparts of its own (such as a description of its own
bottleneck). Although conceivable, there is probably no practical
use-case requiring this functionality.
Franceschini Expires August 13, 2007 [Page 20]
Internet-Draft Bandwidth Metrics February 2007
4. Security Considerations
5. IANA Considerations
6. Conclusions
This document presented new bandwidth metrics designed to precisely
describe the link characteristics. It was shown that the accuracy of
such metrics depends on the measurement point: the closer this point
is to the layer at which the protocol stack portion providing per-
packet overhead interfaces with the protocol stack portion providing
per-byte overhead, the better is the accuracy. The metrics presented
can be interpreted at both media and session level, but if used at
session level allow also to take care of cross-media relations, such
as the induced jitter on the audio due to the serialization of video
packets, or the erosion in video bandwidth due to audio packet
overhead.
An algorithm that takes advantage of the metrics presented to
calculate transmission parameters at a sender peer has been also
described in detail.
A number of additional issues have then been dealt with, leading to a
few ideas on how to extend/modify the metrics presented.
Also, most important, it has been shown that in order to fully
exploit the benefit of the metrics proposed (the usage of session
level parameters to take care of cross-media relations), it is
necessary to consider a new type of RTCP extension, able to carry
session level feedback.
7. Acknowledgments
Franceschini Expires August 13, 2007 [Page 21]
Internet-Draft Bandwidth Metrics February 2007
8. References
8.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
Author's Addresses
Guido Franceschini
Telecomi Italia Lab
Via Reiss Romoli 274
I-10148 Torino
Italy
Email: guido.franceschini@telecomitalia.it
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Franceschini Expires August 13, 2007 [Page 22]
Internet-Draft Bandwidth Metrics February 2007
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Franceschini Expires August 13, 2007 [Page 23]
