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

From: "Lars-Erik Jonsson (EPL)" <[email-masked]>
Date: Sat, 4 May 2002 23:18:47 +0200

Keith,

> I don't see the idea as particularly dangerous - at least, not
> if you're using another IP protocol type. 

This is also the intension, according to the draft (might be
unclear since this was an open issue for a long time, and the
draft might not have been updated to clearly indicate this).

> but requiring IP link layers to be sensitive to 
> higher-layer protocols bothers me, and writing applications 
> without being able to know something about the reliability of
> the underlying service also bothers me.

The application is in control. If an application decides to use
UPD Lite instead of UDP, it asks for a service that provides
error detection for some parts of the data, but not for other
parts. 

Rgds,
/Lars-Erik

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

---

From: Keith Moore <[email-masked]>
Date: Sun, 05 May 2002 01:50:26 -0400

> error detection for some parts of the data, but not for other

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?

also, is it expected that applications written for UDP Lite can
fall back to UDP if either Lite isn't available on both ends,
or it's too unreliable?

---

From: Phillip Conrad <[email-masked]>
Date: Mon, 06 May 2002 06:54:39 -0400

>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

---

From: Michael Welzl <[email-masked]>
Date: 06 May 2002 13:35:31 +0200

... first of all, I just noticed that there is quite a large number
of receivers, including the iesg; if I should leave someone out of
further comments, please indicate.

On Mon, 2002-05-06 at 13:09, Phillip Conrad wrote:
> Michael,
>     The idea of adding optional fields by which lower layers can provide 
> signalling to the application about bit error rates, etc. is 
> intriguing.    I do have some questions about it.
> 
> (1)  While you don't indicate specifically, I'm inferring that these new 
> fields would be in the UDP-Lite Transport Header.  This raises a problem 
> however.  There are two cases:
> 
> (a) These new fields that the router can optionally write into are covered 
> by the transport layer checksum.. (which, even in UDP-Lite, covers 
> transport layer *header* fields.)   This means that router has to recompute 
> the transport layer checksum.  But this cannot be allowed, since it means 
> that the transport layer checksum is no longer truly an end-to-end 
> checksum... and if it isn't that, it has little reason to exist at all.
> 
> (b) These new fields are NOT covered by the transport layer checksum... in 
> which case, the values themselves are subject to bit errors, which would 
> cast doubt on their usefulness.

I would definitely not choose (b). But I don't see why a router could
not recompute the checksum as it updates the new fields; of course, this
is more work for a router ... that's definitely a disadvantage, but
on the other hand, the fields are optional anyway.

When I wrote my comment, I actually already had this alternative
in mind:

> An alternative approach would be to implement the functionality you suggest 
> as an IP-Option rather than as a transport layer option.   The router 
> recomputes the IP layer checksum anyway (due to changing the TTL 
> value.)  This would also make the values available to other protocols 
> besides UDP-Lite (though its difficult to imagine how they would be useful 
> there.)

... and that is exactly why I didn't propose it. Originally, I didn't
expect this information to be useful for any protocol other than UDP
Lite, and therefore, it doesn't make much sense to separate the
design like that. Now that I think of it, a large bit error rate
could be a nice (although rather unreliable) indicator for
congestion control mechanisms. i.e., if the bit error rate is large,
a congestion control mechanism might not have to react as drastically
to packet drops as if the bit error rate is close to 0.

> If these functions are implemented as an IP-option rather than as fields in 
> UDP-Lite, this would probably be done more appropriately in a separate 
> document that could be proposed independently of the UDP-Lite draft.  The 
> UDP-Lite draft would NOT have to be held up while this work proceeds.

I agree.

> However, as I indicated in another note, I'm not sure we need any 
> signalling at all for UDP-lite... the packet error rate that results from 
> IP checksums and the limited UDP-Lite checksum will probably be enough of 
> an indication of what range of BER you are operating in.
> 
> Comments?

In my opinion, it may be neat to have some optional additional
signalling - for example, to indicate which kind of FEC is already
done as I described so that you don't duplicate the functionality.
But I wouldn't consider that a requirement either.

Cheers,
Michael

---

From: Phillip Conrad <[email-masked]>
Date: Mon, 06 May 2002 07:09:27 -0400

Michael,

Comments?

Thanks,
Phill Conrad

At 10:42 AM 5/6/2002 +0200, Michael Welzl wrote:
>On Sun, 2002-05-05 at 07:50, Keith Moore wrote:
>I have a proposal:
>Since UDP Lite is located on top of IP, it will normally not
>be particularly difficult for a router to take a closer look at
>the packet header. Why don't you introduce an
>"Expected Bit Error Rate" field which gives an application
>an idea of the expected bit error rate, and routers _MAY_ write
>it in there? And, if a router which would write something in
>there already finds a value from another router, it updates it
>only if its own Expected Bit Error Rate is worse.
>
>"Its own" of course refers to a link that was or will be
>traversed by the packet.
>
>This can become arbitrarily complicated ... routers could add
>information about loss correlation, about the type of FEC that
>is in use etc. ... I would leave that open for now and actually
>use TWO fields and a bit:
>
>1.) Expected Bit Error Rate - default: 0
>2.) Link Layer Information - default: 0
>3.) Different Link Layer Treatment Bit - default: 0
>
>"Link Layer Information" should be left open for future
>standardization (maybe by IANA, or separate drafts, like the
>payload type stuff for RTP) - a certain number could mean a
>certain type of FEC, for example. If a router which would update
>the "Link Layer Information" field finds a value other than 0
>and different from the value that it would have written in there
>anyway, it should set the "Different Link Layer Treatment Bit".
>
>An application which receives a UDP Lite packet with a set
>"Different Link Layer Treatment Bit" knows that the method
>indicated by "Link Layer Information" is not all... and it should
>therefore not rely upon any mechanism building upon a specific
>Link Layer Information to work.
>
>
>ALL these router updates should be OPTIONAL.
>
>And maybe someone could come up with better names for these fields...
>
>
>If it's too unreliable, they can still use the regular UDP
>checksum within UDP Lite.
>
>As far as falling back to UDP if UDP Lite isn't available is
>concerned, I'm not sure if such end-to-end semantics should
>really be part of the draft...
>
>
>
>Cheers,
>Michael

---

From: Michael Welzl <[email-masked]>
Date: 06 May 2002 10:42:41 +0200

I have a proposal:

Cheers,
Michael

---

From: "Michael A. Ramalho" <[email-masked]>
Date: Mon, 06 May 2002 11:39:02 -0400

At 06:54 AM 5/6/2002 -0400, Phillip Conrad wrote:
>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.
>

<snip>

Obviously Phil's "back of the envelope" calculations (below) to show the 
"sweet spot" of the
benefit of UDP-lite are on the mark (thanks for the reasoned analysis). 
Note that his
calculations assume i.i.d. (random bit) error characteristics, however 
(more on this below).

I however, think that debate is much a do about nothing ... the UDP light 
protocol has
a good purpose for those applications that can benefit from receipt of
"partially-errored payloads".

Most "non-wireless" links are designed for specific BER characteristics. 
This is because
most "non-wireless" links are relatively static in their transmission 
performance
characteristics (perhaps only changing slowly with temperature or similar
external conditions). The i.i.d. (random) error assumption that Phil 
assumed above
should hold for these types of links.

I "think" a lot of the impetus behind UDP-lite applications are real-time media
over wireless links. Wireless links are notorious under fading conditions for
producing correlated bit losses - but these correlated losses might only span a
few bits to a few hundred bits. If this "error burst" doesn't hit the 
header (i.e.,
it hits the payload) ... let the decoder deal with the problem of living 
with the
errors.

I have built speech coders that use median filtering of many of my 
parameters between
packet payloads. If an important parameter deviates significantly from the 
packet to packet
trend (i.e., looks like a statistical outlier based on recent history) ... 
I median filter it. If I
receive the parameter OK on the subsequent packet ... the errored parameter 
never
gets used! Thus, my codec would produce an acceptable output using slightly 
wrong data
(i.e., the median filtered output) ... but would not produce devastated 
output by use
of the "apparent outlier" (probably errored) parameter.

That is, the application (in my case my speech coder) decides if the 
(potentially
errored) packet payload is of any use. I therefore do not think that 
signalling of
an "expected BER" makes much sense in the case of links with correlated (bit)
loss characteristics. Just let me have the payload!

I think this correlated bit loss characteristic on wireless (and IR) links 
is significant
to consider in the age of real-time application mobility. These links are: 
1) not
going away anytime soon, and 2) wireless null/fade characteristics
(producing the errors) are not changing (for a given frequency band in use) 
- physics
reigns here.

My vote would be to let the UDP-lite proposal continue as is (sans a few 
editorial
changes).

Michael Ramalho

>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.
>
>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
>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.
>
>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.
>

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

---

From: "Michael A. Ramalho" <[email-masked]>
Date: Mon, 06 May 2002 14:01:22 -0400

At 12:02 PM 5/6/2002 -0400, Keith Moore wrote:
> > protocol has a good purpose for those applications that can benefit
> > from receipt of "partially-errored payloads".

Keith,

First .. I understand your concerns. But the situation really isn't
any different from today.

For example, V.90 modems have an option for *either* turning on
error correction or not. Of course, for real-time VoIP packets I'd
like to turn it off. But this is not optimum for the data packets which
share the link; we would clearly like the HDLC layer to correct errors
on the link that caused them rather than rely on upper layer protocols
such as TCP (not to mention wasted bandwidth and delay for
not correcting them on the "bad link"). My optimum V.90 link
layer would turn on and off error correction on a packet by packet
basis (using MLPP together with a new HDLC framing, I suppose?).

I hope the radio/cell heads would speak up here ... but I think
that they desire real-time packets (like VoIP) to be sent without
correction and data packets to be sent utilizing correction. Maybe
they are considering link layers that do this (the present generation
of cell phones do have link-layer error correction for the data packets
but do not send voice via VoIP).

>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?

>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.

>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.

>Keith

Michael Ramalho

---

From: Randall Stewart <[email-masked]>
Date: Mon, 06 May 2002 15:10:25 -0500

A comment:

> to packet drops as if the bit error rate is close to 0.

The minute you put in IP-Options most routers will pull this
OUT of the fast path and dump it up to software. Think SLOW SLOW
SLOW.. so IP-Options may help in someways but they surely will
NOT help with your delay.. they will increase it..

R

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)

---

From: "Michael A. Ramalho" <[email-masked]>
Date: Mon, 06 May 2002 16:26:22 -0400

At 02:14 PM 5/6/2002 -0400, Keith Moore wrote:
>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).

>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.
>
>it's not the only concern I've expressed, but it's probably the biggest
>concern.
>
>Keith

---

From: Phillip Conrad <[email-masked]>
Date: Mon, 06 May 2002 08:36:26 -0400

At 01:35 PM 5/6/2002 +0200, Michael Welzl wrote:
...
>on the other hand, the fields are optional anyway.

The router *could* recompute the checksum, but if it does so, it violates 
the 'end-to-end' ness of the transport layer checksum.   I may be mistaken 
about this, but its my understanding that the "end-to-end" ness of the 
transport layer checksum is an important piece of the architecture.  For 
one thing, it provides protection against errors introduced in routers "in 
between" the time the packet leaves the incoming link (where it is 
presumably protected by a link level checksum/CRC) to the point where is 
goes on the outgoing link (where again, link layer protection takes 
over.)   Your suggested design isn't impossible, but I suspect it would 
raise eyebrows.

>But I wouldn't consider that a requirement either.

I agree with the general principle that some additional (optional) 
signalling that would inform upper layers about the lower layer plumbing 
might be helpful to upper layers in many ways: making more intelligent 
decisions about whether packet drops are due to congestion or link 
errors,  letting UDP-lite know whether lower layers support 
partial-checksum along the path, etc. (although we may disagree on the 
details of how such signalling might be done.)

And, if I understand you correctly, it sounds like we agree that isn't a 
requirement for UDP-lite to proceed forward... please correct me if I'm 
misinterpreting your remarks.

Cheers,
Phill

---

From: Michael Welzl <[email-masked]>
Date: 07 May 2002 09:56:14 +0200

Folks,

I'm gonna try and answer two separate mails at once.

Following with my last comment (as a reply to Phillip) about

> NOT help with your delay.. they will increase it..

I know, but don't care   :)
I really don't think that these options should be used with
EVERY UDP Lite payload packet - this should just be used
sporadically. Like a network layer service that can be
requested by the transport layer: "give me a reasonable
BER estimate". The problem is that you get at least one
payload packet that will arrive much later ... but there's
really nothing we could do about that, I suppse.

In a response to Keith, Michael (Ramalho, not met  :)  ) wrote:

> information on the payload (an interesting research topic BTW)? 

That was my original proposal, more or less ... additional fields
in the UDP Lite header. Phillip disagreed with this method because
it has routers recompute the UDP Lite checksum and thus loose
end-to-end data integrity, and he's certainly right.

I am pretty sure that _IF_ we need such signalling, an IP option
would be the way to do it. This way, the information could also
be used by other protocols, although it's hard to imagine which
kind of protocol might use this information. MAYBE some new
congestion control mechanism ... but that would bring about several
complex issues.

Another reason for an IP option: there's no reason for routers
to add the information to EVERY packet. If you add special fields
to UDP Lite, you either request the information all the time or
you're wasting space.

> links would be significantly different.

That sounds reasonable to me. I don't think we should create an
IP option (or any other kind of link layer information signalling)
unless somebody can come up with a good metric (e.g.,
a degree of how correlated bit errors are?) and probably
some proof that this metric is actually useful for the application.
I'm cc'ing AVT...

Cheers,
Michael

---

From: Michael Welzl <[email-masked]>
Date: 06 May 2002 14:55:22 +0200

> over.)   Your suggested design isn't impossible, but I suspect it would 

You're right, that makes a lot of sense to me.
If an intermediate system was to alter the checksum of a transport
protocol, we'd be at a similar level of losing data integrity as with
the idea of Open Pluggable End Services. I did not see that point.

> details of how such signalling might be done.)

Do we? I now fully agree that an IP option would be a better idea
than changing fields in the UDP Lite header.

> misinterpreting your remarks.

I absolutely agree that UDP Lite can proceed.

Cheers,
Michael

---

From: Keith Moore <[email-masked]>
Date: Mon, 06 May 2002 21:06:45 -0400

> 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.

it makes me wonder if UDP Lite really is that useful if the app can't
assume anything about the link.   but my guess is that the folks who
want this have implicit assumptions about link error rates - I'd
like to see those assumptions made more explicit.

I suppose the app can implement its own error recovery algorithms
appropriate to the app - trading off bandwidth (FEC) or time 
(interleaving) to obtain closer-to-ideal error characteristics,
but it's going to have to measure the error characteristics by 
itself and the feedback loop will be over the entire IP signal 
path rather than just the noisy link. so it will be slow to adapt.
It seems suboptimal - surely there are links that are so noisy
that producing an acceptable error rate is better served by 
link-level mechanisms, even for users of UDP Lite, than by 
end-to-end mechanisms.  it's not as if UDP Lite is going to make
the rest of the IP signal path jitter-free anyway.

But if this is what is being assumed then please just say so.
If something else is being assumed then explain what that is.
There's just too much left out of the current document, and I
I don't think either link designers or app designers should
have to guess.

Keith

---

From: Keith Moore <[email-masked]>
Date: Mon, 06 May 2002 12:02:19 -0400

use it where the error rate is unacceptably large, and by link 

Keith

---

From: Keith Moore <[email-masked]>
Date: Mon, 06 May 2002 14:14:03 -0400

Keith

---

From: Keith Moore <[email-masked]>
Date: Mon, 06 May 2002 11:13:43 -0400

Phill,

that's an interesting analysis. I'd like to see this kind of explanation
made a part of the RFC, perhaps as an appendix, to explain the applicability 
of UDP Lite.  (i.e. it's for channels with a BER in the range...)

Keith

---

From: "Michael A. Ramalho" <[email-masked]>
Date: Wed, 08 May 2002 09:35:08 -0400

Keith,

After this discussion ... I'd agree that some more words to describe the
algorithm would be a good thing (comments on this below).

I'll add a comment or two below ... but you did *not* take me up on
my challenge to describe a metric or a mechanism that would signal the
"characterization" of link quality you desire.

Regards,

Michael Ramalho

>like to see those assumptions made more explicit.

OK

>path rather than just the noisy link.

["going to HAVE to .."?]

Not necessarily. I gave you an explicit example yesterday of a
codec I designed that depended on the observation of how important
parameters trended from frame to frame to make decisions on the
validity of the data. This is because the error bursts are so
unpredictable and non-stationary as to render *any* error metric
unusable.

What you suggest is OK for stable (in error characteristic) channels.
Did you read the debate I presented earlier? I addressed this point
in depth.

>so it will be slow to adapt.

.. and make the resultant measurement even more meaningless.
Think "bursty/fractal" error characteristic channels.

>end-to-end mechanisms.

Depends on the link. For short (time) delay links ... some
limited persistence (retransmission) mechanisms are of
value .... particularly if (in the statistical sense) they will
retransmit outside the "mean burst length time" of the error
characteristics of the channel. I am assuming that link layers
take advantage of such techniques (by defining the right
level of persistence, etc.) where the additional delay due
to retransmission is small in comparison to a hypothetical
model of mean end-to-end delay. Good link designers can
do this (they know the fading/error characteristics given
the frequency band and the modulation schemes used).

But many links fade over a few seconds ... rendering such
persistence of little value (the retransmission is also killed
due to the time length of the null event and too much delay
is introduced). Cell phones are typical examples (where you
send the voice payload once and forget it).

>it's not as if UDP Lite is going to make

I now agree that if someone as knowledgeable as you are have
this many concerns ... that people of lesser grey matter means
might benefit from additional guidance. If the authors, Phil or
others want to come up with something with me ... I'm game.