Subject: Re: Continuation of Thread: UDP Lite

From: Mikael Degermark <[email-masked]>
Date: Mon, 30 Aug 1999 05:51:26 +0200

Vernon,

Is it fair to say that your position is that:

   It is of no use to develop a protocol like UDP Lite until there are 
   framing protocols over which UDP Lite would provide better services.

If so, I would counter with the observation that unless there is a transport
protocol like UDP Lite, those framing protocols will not be developed.

Do you really want to dismiss a good solution (and there are
numbers which show that it in fact is a good solution) just because the
complete solution cannot be specified in all its details right now?

For each link-layer with partial checksumming features over which UDP Lite
will be used, there will of course be RFCs describing how UDP Lite packets
are to be mapped onto those link-layers. But I don't see how we can 
produce those RFCs at this time. Neither do I see why that fact has 
anything to do with whether we should discuss pros and cons of UDP Lite 
here and now.

Mikael Degermark

http://www.cdt.luth.se/~micke

---

From: Mikael Degermark <[email-masked]>
Date: Mon, 30 Aug 1999 05:50:52 +0200

(sorry about the length of this note) 

Reiner is not an author of the UDP Lite draft and has had nothing to do 
with it until he got involved in this discussion. In fact, nobody
at Ericsson has so far been involved in developing UDP Lite. 

1. Fragmentation:
UDP Lite provides a way for an application to optionally leave part of 
a packet unprotected by the transport layer checksum. 
The implicit requirement on lower layers is then to protect *at least* 
the protected part with strong checksums (or other methods).

This provides a partial answer to the questions on fragments. The application
we've looked carefully at so far has been voice, where fragments are a non-
issue because the packets are so small. However, if UDP Lite datagrams are
large enough to be fragmented, it would be "legal" for a non-sophisticated 
link-layer to checksum all of non-first fragments (although that may be bad 
for performance), if there isn't enough information available to checksum 
only the protected part. (This should be discussed in the UDP Lite draft)

2. Partial checksumming in lower layers:
The checksumming policy of UDP Lite needs to be reflected down to lower
layers. To the link-layer, of course, but we can see from the fragmentation
problem that it might also be reflected down to the IP layer. If there was
enough information in the IP header (or an extension header), the
fragmentation
problem would be simple to solve well. That would also avoid signalling which 
some people have proposed to deal with the problem of figuring out 
how much the link-layer checksum should cover. It would be more 
robust to have explicit information in the packet than to rely on signalling. 

3. Our simulations:
Jonathan claims that the numbers in our simulations don't add up. 
They do. The simulations are for a new header compression scheme over
3rd generation cellular links with relatively bad but not unrealistic 
error characteristics. These links will have more than one logical radio
channel, and it would make sense to have UDP-Lite enabled framing only
on the links where the traffic benefits from it. So the price of an
extra length field in the framing would be paid only over those links. 

We use two different framing protocols in our simulations: 
One with a checksum that extends over the entire frame, and one with a
checksum that extends only over the compressed header. A one-byte length
field specifies how much the checksum covers. 

It turns out that the framing protocol with partial checksums gives a drop
rate which is around 40% lower than the one with full checksums (if I remember
the numbers correctly). 
 
Jonathan also asks about the e2e checksum, which of course isn't there since
we explicitly state that the results are for UDP with the checksum disabled.
As we all should know by now, disabling the UDP checksum is the only way to
have damaged packets delivered to the application with current transport
protocols. And that can only be done with IPv4, not with IPv6.

The results are of interest since the numbers for UDP Lite would be 
the same as for UDP with a disabled checksum. We didn't mention UDP Lite in
the draft since the header compression scheme is somewhat independent of 
UDP Lite. 

4. Concerning the UDP Checksum in the header compression draft:
If UDP Lite does not happen, it is almost inevitable that engineers doing 
cellular voice will remove the UDP checksum for voice packets over the
cellular link, since it doesn't provide a useful function for (at least
some) cellular voice, and they would argue that it costs too much in terms
of radio spectrum to always send it. Therefore we have outlined ways to
maintain the *semantics* of the UDP checksum across the compressed link,
without sending it in full. 

I agree that this is far from a satisfactory solution (so I do hope 
UDP Lite happens), but compared to violating the UDP checksum semantics
by not sending it over the link and then recomputing it over the (possibly
damaged) payload in order to make sure the receiving UDP delivers the packet
to the app, it is certainly less evil. 
 
5. Discussing framing protocols here?
I don't have a strong opinion about whether the framing protocols should
be discussed here or not. The standardization body which will
develop framing protocols for 3rd generation cellular will probably not be
the IETF. On the other hand, the mapping of UDP Lite packets to specific 
link-layers would probably be done in the IETF.
 
Jonathan Stone wrote:
>Micke also ruled out one very plausible design alternative on the
>basis that there ``isn't space'' for another 2 bytes for an e2e
>checksum over the `uncovered' payload. 

That is not why I ruled it out. Let me clarify:

1. There are applications which do not need or want an e2e checksum
over the entire payload in addition to the UDP Lite checksum.
2. The octets of the additional checksum would hurt the performance for 
apps sending small packets, such as interactive voice.
3. An application which wants such an additional e2e checksum can provide it
itself without a performance penalty. 
4. So, why have it there? It wouldn't buy us anything and it would hurt
at least some applications to have it there. 

>Micke also says that he can compress away the UDP-Enhanced hecksum
>Coverage field.  How, then, can the receiver verify the link-level CRC
>on the frame? 

As we explain in the draft: In the non-standard framing protocol we used,
there was a length field which explicitly stated the number of bytes to
be checksummed - a link-layer equivalent of the UDP Lite Coverage field.
The UDP Lite Coverage field can easily be extracted from the value in the
frame, so it is trivial to compress. It is also trivial to verify the 
partial link-level CRC.

We don't know yet, however, whether the real framing protocols will
be like that. 

>Reading between the lines, I can guess at what Micke intends,
>but I wish he'd just tell us.

I don't know what you are getting at, but *please* don't guess or
read between the lines. 

Let's sort this out offline if you still find that something 
is not clear. 

Micke

---

From: Vernon Schryver <[email-masked]>
Date: Mon, 30 Aug 1999 10:39:49 -0600 (MDT)

> To: Vernon Schryver <[email-masked]>
> From: Mikael Degermark <[email-masked]>
> Cc: [email-masked], [email-masked]

(I'm hoping against hope that the end2end and PILC lists are somehow
syncrhonized so that at least some of us will not all have to deal with
several copies of every message.  I will continue to trim my addressee
lists to only the mailing lists, so you won't have to see more than 2
copies of my words.  Dealing with 2 or 3 copies of everything is a pain,
but it seems to be necessary to get past the forum objections.)

>    framing protocols over which UDP Lite would provide better services.

No, that is not fair, and I consider it an offensive misrepresentation
of my often repeated words, including my recent words that you received:

] The framing protocols need not exist, but their general nature MUST be
] known.

> anything to do with whether we should discuss pros and cons of UDP Lite 

There is no technical content in those words that I can see.  It does
contain obvious misrepresentations of my position, including the
implication that I have ever said that such RFC's need ever be written,
not to mention before a UDP-lite RFC.  It also falsely implies that I have
been among those objecting to talking about the technical issues.  It also
falsely implies that I have ever said that a complete solution need be
specified now.  Please stop such rhetoric, and let's talk about the real
issues.

I see the real issue as basically:

   Is UDP Lite the best way to accomodate the lossy, error prone mobile
   phone links envisioned in Scandanavia and expected by some to be common
   elsewhere?

I think it can be divided into:

   0. what are the design goals addressed by UDP Lite?

      Besides the possibly obvious technical goals about lossy, error prone
      mobile phone links, attention should be given to non-technical
      issues.  After thinking about the new, apparently r digitial mobile
      phone offerings in the U.S., I wonder about the notion of
      1,000,000,000 users of a single phone-to-phone radio voice protocol.
      Where telcos are allowed to compete on the radio waves, they have
      incentives to use a sufficient proprietary protocol between their
      radio towers and phones to "lock-in" customers.  Am I wrong in
      inferring that the 2 or 3 "PCS" services offered in the Front Range
      (i.e. eastern slope of the U.S. Rocky Mountains) are incompatible
      at the phones?  My wife's Sprint phone seems distinctly customized to
      Sprint's services.

   1. what are the general characteristics of the anticipated lossy, error
       prone radio links, in terms of

       - bit error rates (including all modes if there are more than
          one mode, as seems to be assumed by UDP Lite),

       - packet error rates (also including all relevant modes)

       - delays (also including all modes)

       - frame/packet/cell sizes that the medium likes (again in all modes)

  2. what are the general characteristics of the IP traffic expected 
     for these links, including the relative and perhaps absolute
     prevalence of 

      - classic, error intolerant IP traffic,

      - current or classic voice/IP traffic,

      - future, error-tolerant, especially voice traffic

  3. exactly how many bits/packet does UDP-Lite save, including Jonathan
      Stone's repeated and evidently unaddressed concerns.

  4. alternatives to end-to-end UDP-Lite, including but not limited to

      - gateways in the radio towers that convert from classic voice/IP
       traffic to some other form, whose alternatives include but are not
       limited to:
          -- UDP-Lite
          -- UDP with checksum=0
          -- a proprietary or at least non-IETF form

      - doing nothing, on the grounds that most of the radio traffic will
       be error intolerant, and so nothing significant is to be gained
       by doing anything special for error tolerant voice.

   5. whether UDP Lite is a good idea as it would actually be implemented
      and used, including:

      - the words in more than one document that talk about completely
        compressing the UDP checksum out of at least some radio traffic.

      - exactly what sort of protection the UDP header would receive from
        the radio link layer, perhaps as measured in bit error rate.

      - whether UDP lite would an "attractive nuisance" for misuse on the
       Internet and local area networks by the people who do not believe
       in the UDP and TCP checksums.  (My little system running BSD/OS
       claims to be seeing a lot UDP packets with checksum=0.  I think
       that is a Bad Thing(tm).)

Vernon Schryver    [email-masked]