Subject: RE: [Tsvwg] Re: Last Call: The UDP Lite Protocol to Proposed Stan dard

From: "Peter Barany"<[email-masked]>
Date: Mon, 6 May 2002 08:45:19 -0500

Hi,

A typical application that might use UDP Lite would be, for example, 3GPP
UMTS packet-switched voice (via the RTP payload format for the AMR speech
codec).

For such a scenario, it can be anticipated that the RTP/UDP or UDP Lite/IPv6
header will be compressed over the air interface using a an
existing/modified ROHC profile (depending upon whether UDP or UDP Lite is
used as the transport layer protocol) (see IETF ROHC WG work on this).
Therefore, the header size you mention below will typically not be RTP (12
bytes) + UDP or UDP Lite (8 bytes) + IPv6 (40 bytes). NOTE: I use IPv6
because it is the network layer protocol mandated by 3GPP for use with
packet-switched multimedia services.

Also, for the RTP payload format for the AMR speech codec, you might expect
an RTP payload size of around 32 bytes for the highest codec rate of 12.2
kbps (assuming one speech frame per RTP packet).

Finally, the formula you use below is accurate/correct only if you have
random errors (i.e., uncorrelated) such as would be the case, for example,
with a binomial pdf. But wireless channels cannot be modeled this way. 

Therefore, I am not convinced that your calculations below are meaningful
for an air interface like 3GPP UMTS (or any other cellular system using
header compression).

Now, once the RTP/UDP or UDP Lite/IPv6 reach the landline network, it is
anticipated that the BER will drop dramatically due to the nature of the
landline network vs. a cellular network (also, the BER pdf will more closely
resemble the binomial distribution you use in your formula). But the
potential benefits of UDP Lite are not really targeted for landline
networks. So, we are really talking about the benefits of UDP Lite over an
air interface that exist in, for example, cellular networks.  

FYI. Also, for IPv6, there is no header checksum as there is with IPv4.

Regards,

Pete

-----Original Message-----
From: Phillip Conrad [mailto:[email-masked]]
Sent: Monday, May 06, 2002 5:55 AM
To: Keith Moore; Lars-Erik Jonsson (EPL)
Cc: [email-masked]; [email-masked]
Subject: Re: [Tsvwg] Re: Last Call: The UDP Lite Protocol to Proposed
Standard

At 01:50 AM 5/5/2002 -0400, Keith Moore wrote:
>right, but without having some idea of the expected error rate,
>on what basis does the application decide whether to use it?
>even those codecs that can handle some bit errors have limits
>to how much they can handle, don't they?

Actually, I think some back of the envelope calculations will show that the 
BER over which UDP-Lite will deliver packets to the application is someone 
limited by the fact that we still have an IP checksum being enforced, and a 
checksum over the UDP header plus the IP pseudoheader.

Consider how a bit error rate translates into a packet error rate.   PER = 
1-(1-BER)^n  where n is the length of the packet.   Now, realize that the 
purpose of UDP-Lite is to allow packets through that have one or more bit 
errors in the data portion of the packet, but NOT in the header portion of 
the packet.

Thus, UDP-Lite provides advantage when it is significantly more likely that 
a packet will be dropped if the checksum is computed over the whole packet, 
than when it is computed over only the header.     If the BER is too high, 
then you'll likely lose all your packets even if you only compute the IP 
checksum.  If the BER is too low, then the "savings" from UDP-lite of 
packets that get "delivered damaged" instead of being dropped is likely to 
be very small.

This implies that there is a "sweet spot" in the middle.  A quick back of 
the envelope calculation verifies this (well, ok, I used a 
spreadsheet.)  The table below shows the PER, computed by the formula above 
for various BERs, comparing 224 bits (20 IP + 8 UDP lite) vs. 1500 bits 
(common IP datagram size).    This is slightly off, not taking into account 
the difference betwen the actual IP header, and the 'pseudo-header' used in 
checksum calculations, but I did say this was a "back of the envelope" 
calculation.

BER\n2241500Difference
0.11.000001.000000.00000
0.010.894741.000000.10526
0.0010.200770.777040.57626
0.00010.022150.139300.11715
0.000010.002240.014890.01265
0.0000010.000220.001500.00127
0.00000010.000020.000150.00013
0.000000010.000000.000010.00001
0.0000000010.000000.000000.00000

If we believe the table (and I hope someone will do the calculation 
independently to see if I'm way off here), then for BER of 1E-3, UDP-Lite 
is a big win... we would throw away 77% of the packets if we did a full 
checksum, but only 20% of the packets if we use a UDP-Lite checksum.

But, at BER 0.01, we are throwing away almost 90% of the packets 
anyway!  And for BER's of 1E--4, 1E-5 and 1E-6, the benefit is on the order 
of 10%, 1%, 0.1% respectively.

Therefore, the range of BER's where UDP lite is a "big win" is probably 
fairly limited...  which is not in any way to imply that UDP-lite is not 
useful or needed!   I read these numbers to suggest that in a certain 
niche, it can be very useful.

I am only suggesting that  you won't need much signalling to figure out 
which range of BER you are in; the packet error rate based in IP checksums 
and the limited UDP-Lite checksum will probably be enough of an 
indication... and in fact, the partial checksum over the header will server 
to limit the BER that upper layers are exposed to in the unchecked portion 
of the packet.

I would welcome comments on this...

Thanks,
Phill Conrad

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

---

From: "Peter Barany"<[email-masked]>
Date: Mon, 6 May 2002 16:00:35 -0500

Michael,

What you say below regarding wireless link layer performance is correct
(also, making matters more complicated, there is the physical layer to
consider and all of the different convolutional coding, interleaving, etc.
schemes for all of the different radio access technologies and their
associated data rates that need to go into the soup).

For some "text" regarding the usage of UEP/UED and UDP Lite for the RTP
payload format for the AMR speech codec, see Section 3.6.1 of
<draft-ietf-avt-rtp-amr-13.txt>. Perhaps we can move forward with some
generic "text" like this if everyone feels that some guidelines on the usage
UDP Lite need to be included in the UDP Lite Internet draft (other than what
is already in the Internet draft, that is). Thanks.

Regards,

Pete

-----Original Message-----
From: Michael A. Ramalho [mailto:[email-masked]]
Sent: Monday, May 06, 2002 3:26 PM
To: Keith Moore
Cc: Keith Moore; Phillip Conrad; Lars-Erik Jonsson (EPL); [email-masked];
[email-masked]

At 02:14 PM 5/6/2002 -0400, Keith Moore wrote:
> > >I don't doubt that at all - my concern is that it can be misused
> > >by both applications and link layers  - by applications if they
> > >use it where the error rate is unacceptably large,
> >
> > shame on those applications - but can we legislate non-stupidity
> > of such application designers?
>
>if they aren't told what to expect in terms of error rates, and are
>forced to guess - it's not stupidity on the app designers' part,
>it's a failure on OUR part.

I've tried to explain that some of the links that we will be "stuck" with
(due to RF/IR/radio propagation characteristics) will have highly
varying error characteristics - ones which produce *time-varying*,
non-ideal (i.e., non-random) error characteristics. What type of
"guidance" can we give the application designer?

Short of constantly signalling like signal to noise ratio (or something
that characterizes short-term average error performance) ... I don't
know what type of guidance to provide. What do you do when you go
through a radio null .... and that kills part of your packet payload ... 
and this
even happens once every 5 minutes or so. The average error rate is near
zero ... but you get significant error bursts in otherwise useable real-time
payloads..... and the UDP-lite application desires the damaged payload
when this error event occurs.

Are you proposing a UDP-lite protocol that can piggyback link performance
information on the payload (an interesting research topic BTW)? Generic
guidance won't help any particular application designer ... except that
error performance over any short-term interval can be arbitrarily bad.
That's
not much guidance in my book (but one I would assume for wireless type
media codec applications).

> > >and by link
> > >layers if they implement udp lite using a transmission mechanism
> > >(e.g. omitting FEC or link-level retransmit) which provides an
> > >larger error rate than applications can reasonably expect.
> >
> > This opens up the discussion of link layer behavior (in this case
> > error correction or not) with differing packet payloads/flows. This
> > discussion needs to be aired ... but I think it is orthogonal to the
> > UDP-lite discussion.
>
>strongly disagree.  again, if a link that treats UDP lite differently
>doesn't make some reasonable assurances about error rates of the payloads,
>the application protocol designer won't know whether it's safe to use
>UDP Lite for his application or not.

Rather than continuing this discussion ... please propose a metric (or
guidance) you want to use that is generic enough for most/all links.

Warning: an average error-rate metric is probably of little value ... there
are sharp knees in S/N vs. BER curves. I only wish we could mandate
good/clean/predictable wireless/IR links for the "reasonable assurances"
you desire above for some of these links... but I can't. Cellular phones
prove that otherwise unacceptable audio performance is tolerated in exchange
for another benefit (mobility). There is no reason to believe that wireless
IP
links would be significantly different.

>what seems to be going on now is a kind of "ah, it will be good enough"
>handwaving which doesn't seem appropriate for an engineering discussion.
>
> > >if the RFC provides some guidance about acceptable error rates
> > >for UDP-lite, the risk of misuse is minimized.
> >
> > I think you and I could forward some text if the UDP-lite authors
> > desire ... if this is your only concern.
>
>it's not the only concern I've expressed, but it's probably the biggest
>concern.
>
>Keith

Michael A. Ramalho, Ph.D.
Office email: [email-masked]
Personal email: [email-masked]
Office: +1.732.449.5762
Cell: +1.732.809.0188

---

From: "Peter Barany"<[email-masked]>
Date: Wed, 15 May 2002 05:43:29 -0500

Hi,

A new topic in regards to the UDP Lite Internet draft.

In the Section entitled "Backwards compatibility", the following statement
is made:

"If UDP Lite has its own separate protocol identifier, on the other
hand, a system unaware of UDP Lite would return ICMP Protocol
Unreachable error messages to the sender. This simple method of
detecting UDP Lite unaware systems is the primary benefit of having
separate protocol identifiers."

This is fine. But for real-time multimedia applications (which UDP Lite is
aimed at), some mention of the possible usage of an out-of-band negotiation
mechanism might be prudent (e.g., an extension to SIP/SDP and/or RTSP/SDP to
indicate the preferred transport layer protocol for RTP), although such an
extension to SIP/SDP and/or RTSP/SDP have not yet been defined or proposed.

The delay involved in using ICMP messages as the only mechanism to determine
whether or not another host/server supports UDP Lite would render UDP Lite
useless.

Regards,

Pete

-----Original Message-----
From: Allison Mankin [mailto:[email-masked]]
Sent: Monday, May 13, 2002 8:37 AM
To: Keith Moore
Cc: [email-masked]
Subject: Re: [Tsvwg] Re: Last Call: The UDP Lite Protocol to Proposed
Standard 

> > I see no point in delaying the core UDP-Lite draft to address these 
> > issues.   
>  
> The reason for doing so, of course, is to delay the document until it 
> can be clarified to the point that applications using UDP Lite - now  
> and in the future - are likely to be able to interoperate when their 
> signal paths employ links that treat UDP Lite differently than other 
> IP traffic. 

Keith,

Please explain what _protocol interopability_ issue you see with
UDP-Lite.  

Allison