Subject: [Tsvwg] AD review of draft-ietf-tsvwg-udp-guidelines-08

From: "Magnus Westerlund" <[email-masked]>
Date: Fri, 4 Jul 2008 11:20:40 +0200

Hi,
 
I have done my AD review of this document and have a few questions and
comments.
 
1. Section 3.1:
 
  "In the past, the IETF has also investigated integrated congestion
   control mechanisms that act on the traffic aggregate between two
   hosts, i.e., across all communication sessions active at a given time
   independent of specific transport protocols, such as the Congestion
   Manager [RFC3124].  Such mechanisms have failed to see deployment,
   but would otherwise also fulfill the congestion control requirements
   in [RFC2914], because they provide congestion control for UDP
   sessions."
 
I think this paragraph is incorrectly describing what the congestion
manager is doing. Also for UDP the individual flow needs to provide
feedback information to the congestion manager. As described in Section
5.1.2, this could either be done on the application layer or by the
corresponding sides network stack. I think the current text is
missleading in that the congestion manager is some magic that resolves
everything without any changes to the application. 
 
2. Section 3.1.2:
 
  "Applications that communicate bidirectionally SHOULD employ
   congestion control for both directions of the communication.  For
   example, for a client-server, request-response-style application,
   clients SHOULD congestion control their request transmission to a
   server, and the server SHOULD congestion-control its responses to the
   clients.  Congestion in the forward and reverse direction is
   uncorrelated and an application SHOULD independently detect and
   respond to congestion along both directions."
 
Although correct I think this is difficult to implement in many request
response applications of the type, one single request UDP datagram
results in a single response UDP datagram. In these application the end
result is that the two paths has to be viewed as a single one and where
the requestor is the one steering the congestion control, by limiting
the requests (new or retransmissions) based on the previous ones. I
think this is worth discussing as the solution for this type of
applications.
 
3. Section 3.4:
 
  "The UDP checksum provides assurance that the payload was not
   corrupted in transit.  It also allows the receiver to verify that it
   was the intended destination of the packet, because it covers the IP
   addresses, port numbers and protocol number, and it verifies that the
   packet is not truncated or padded, because it covers the size field.
   It therefore protects an application against receiving corrupted
   payload data in place of, or in addition to, the data that was sent."
 
I think the word assurance is to strong here. There is a statistical
probablility for detecting non-malicious corruptions. Nothing more. I
think the paragraph may also benefit from including a clarification that
it deals with accidental or non-mailicious corruptions. 
 
4. Section 3.4.1:
 
  "The receiver MUST set a minimum coverage threshold for incoming
   packets that is not smaller than the smallest coverage used by the
   sender.  This may be a fixed value, or may be negotiated by an
   application.  UDP-Lite does not provide mechanisms to negotiate the
   checksum coverage between the sender and receiver."
 
Isn't this text significiantly tightening the requirements on the
receiver for UDP-Lite? The UDP-Lite spec says in Section 3.3:
"There should also be a way to pass the Checksum Coverage
   value to the receiving application, or at least let the receiving
   application block delivery of packets with coverage values less than
   a value provided by the application."
 
I don't see this making it a strict requirement at all for having the
receiving application install a smallest acceptable coverage field value
at all. There clearly are applications where you would assume to trust
the sending application to set sensible coverage for the checksum and
the receiver can't know what the right value is. So I would suggest that
the normative text above is rewritten to something like:
 
The receiver SHOULD set a minimum coverage threshold for incoming
packets to block packets with inappropriately short coverage fields.
 
5. Section 5:
 
   | for non-bulk transfers,                                 | 3.1.2   |
   | SHOULD measure RTT and transmit 1 datagram/RTT          |         |
   | else, SHOULD send at most 1 datagram every 3 seconds    |         |
 
I would suggest to fit in a "max" in the second line so it reads:
 
   | for non-bulk transfers,                                 | 3.1.2   |
   | SHOULD measure RTT and transmit max 1 datagram/RTT      |         |
   | else, SHOULD send at most 1 datagram every 3 seconds    |         |

Cheers
 
Magnus