Re: Last Call: 'A Lightweight UDP Transfer Protocol for the the Internet

Hi,

On Aug 16, 2006, at 17:55, Andrew Newton wrote:
> Harald Alvestrand wrote:
> > There's nothing in the document that says "if you want to send  
> > 4000 requests, and 70 out of the first 100 get lost, you should  
> > slow down your sending rate to that server".
> I just checked the simple user-drive, cli client I wrote and it  
> doesn't retransmit at all (perhaps not the best UI experience).
the issue isn't with retransmissions. If - to use Harald's example -  
no reply arrives for 70 out of 100 issued requests, this is a pretty  
strong indication that the server or something on the way to or from  
the server is congested. In response to such a signal, the request  
rate should be reduced.
One reason is that injecting traffic at a higher rate than the  
network can handle is obviously bad. A second reason is that assuming  
that the sender is interested in receiving responses, it should  
really try to issue them at a rate that attempts to maximize the  
response rate.
At which point we're basically talking about congestion control. I'd  
really like to avoid redesigning congestion control mechanisms inside  
application-layer protocols.
Thus, have you looked at DCCP as a transport? It's basically a  
congestion-controlled UDP. Unlike UDP, it requires a handshake, so  
there is some overhead, but for larger request loads this should be  
negligible. And it might be OK to keep using UDP for very small  
request loads, where the overhead would matter.
I'd also like to bring up a second, somewhat related issue. Section 3  
says:
   Each IRIS-LWZ query or response is contained in a single UDP packet.
   Servers MUST be prepared to accepted packets as large as 4000  
octets,
   and clients MUST NOT send packets larger than 4000 octets.

and Section 4 says

   2.  If a request is less than or equal to 4000 octets, send it
       uncompressed.

   3.  If a request can be compressed to a size less than or equal to
       4000 octets, send the request using compression.  Otherwise use
       another transfer protocol.

Sending packets larger than the minimum MTU of ~512 bytes is likely  
to cause fragmentation, which can significantly reduce transmission  
efficiency and reliability [1] and cause data corruption [2].
Fragmentation becomes more likely as packets get larger. With packets  
of 4000 bytes (where does this number come from, anyway?),  
fragmentation is pretty much guaranteed across most links. If IRIS- 
LZW messages are expected to be larger than ~512 bytes in general,  
the use of a transport protocol other than UDP is probably a good idea.
Lars

[1]   Kent, C. and J. Mogul. Fragmentation Considered harmful.
      Proc. ACM SIGCOMM, Vol. 17, No. 5, October 1987.

[2]   Heffner, J., M. Mathis and B. Chandler. Fragmentation Considered
      Very Harmful. Internet Draft draft-heffner-frag-harmful-02,
      Work in Progress, June 2006.
--
Lars Eggert                                     NEC Network Laboratories

smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf