Subject: Re: [Tsvwg] AD review of draft-ietf-tsvwg-udp-guidelines-08 - suggested new text

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 07 Jul 2008 15:11:16 +0100

Thanks Magnus, see comments in-line. Lars and I have discussed these AD 
questions, and these seem reasonable requests for clarification. We are 
proposing some updated text below and sending this to the list to see if 
others would like to comment.

Best wishes,

Gorry & Lars

---

Magnus Westerlund wrote:
> 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.
>
This could be a valid comment, CM, only provided a framework, would this
seem any better to you:

OLD:
"i.e., across all communication sessions active at a given time
     independent of specific transport protocols, such as the Congestion
     Manager [RFC3124]"

I suggest NEW:
"i.e., a framework such as the Congestion Manager [RFC3124], where
active sessions may share current congestion information in a way that
is independent of the transport protocol."

> 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. 
>
OK - seems like something hard to implement.

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

OLD:
"Congestion in the forward and reverse direction is
uncorrelated and an application SHOULD independently detect and
respond to congestion along both directions."

NEW:
"Congestion in the forward and reverse direction is
uncorrelated and an application SHOULD either independently detect and
respond to congestion along both directions, or limit new and
retransmitted requests based on acknowledged responses across the entire
round trip path."

>  
> 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.
>  
NEW:
"The UDP checksum provides a statistical guarantee 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. This check
                                                              ^^^^^^^^^^
is not strong from a coding or cryptographic perspective, and is not
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
designed to detect physical-layer errors nor to detect malicious
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
modification of the datagram [RFC3819]."
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^?????????

We could refer to section 8.3 of RFC3819 for more details?

> 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? 
>
I don't think so.

> 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. 
>
I understood, the default receiver coverage is the whole datagram, e.g.
  " Applications that wish
    to receive payloads that were only partially covered by a checksum
    should inform the receiving system by an explicit system call."
This also is what the MIB says [rfc5097].

> 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. 
>
Agreed. But this application  accepts partially covered packets, setting
coverage to the minimum, and therefore has to provide its own methods to
know if the payload is valid.

> 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.
>  
Ah, maybe that also a good message.

NEW:
The receiver must set a minimum coverage threshold for incoming
              ^^^^
packets that is not smaller than the smallest coverage used by the
sender [RFC3828]. The  receiver SHOULD select a threshold that is
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
sufficiently large to block packets with an inappropriately short
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
coverage field. 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."

> 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    |         |
>   
>  
Looks good to me.

> Cheers
> Magnus

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 08 Jul 2008 14:50:04 +0200

Hi,

I have some comments on your proposed text. Clearly making progress.

Gorry Fairhurst skrev:
>> 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 

I think this is an improvement. However, I think there still are an 
issue with the later sentence. I think the issue is this part:

"because they provide congestion control for UDP sessions."

Which isn't true as you anyway need to have a feedback mechanism in your 
UDP application to help provide the state for the congestion manager.

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

sounds good.

>> think the paragraph may also benefit from including a clarification 
>> that it deals with accidental or non-mailicious corruptions.
>>  
> NEW:

Yes, that sounds good.

> We could refer to section 8.3 of RFC3819 for more details?

May be valuable if one really likes to dig into this.

>> receiving application install a smallest acceptable coverage field 
>> value at all.

Okay, I didn't get that. I think the fact that default also for UDP-Lite 
is full coverage and any application desiring to set a partial coverage 
is required to communicate this to lower layer should be put in before 
the normative statements as explanation why.

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

I think this new paragraph is great. But it needs the motivational start 
for the first sentence to explain that it is due to that default is full 
coverage.

>>    | else, SHOULD send at most 1 datagram every 3 seconds    |         |

good

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Färögatan 6                | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Lars Eggert <[email-masked]>
Date: Tue, 8 Jul 2008 16:16:38 +0300

> I have some comments on your proposed text. Clearly making progress.

Attached is an attempt at taking Gorry's suggestions as a basis and  
editing them in reponse to your follow-up. Let me know if this  
addresses your review.

Lars

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 08 Jul 2008 15:35:56 +0200

Lars Eggert skrev:
> editing them in reponse to your follow-up. Let me know if this addresses 
> your review.

Seems fine.

Cheers

Magnus Westerlund

---

From: Lars Eggert <[email-masked]>
Date: Tue, 8 Jul 2008 16:43:41 +0300

>> editing them in reponse to your follow-up. Let me know if this  

Great, I'll submit this as -09 then.

Lars