Subject: Re: FW: [rohc] NACK draft comments

From: Adam Roach <[email-masked]>
Date: Wed, 20 Oct 2004 17:12:36 -0500

So, I'm finally getting around to updating the NACK draft based on last 
call comments. Actions detailed inline.

Surtees, Abigail wrote:

>Suggested text:
>
>"  When a NACK is received for a message sent over a reliable transport,
>   the SigComp layer must indicate to the application that an error has
>   occurred.  In general, the application should react in the same way
>   as it does for any other transport layer error, such as a TCP
>   connection reset.  For most applications, this reaction will
>   initially be an attempt to reset/re-establish the connection, and re-
>   initiate the failed transaction.  The SigComp layer should also use the
>   information contained in the NACK to make appropriate adjustments to the 
>   compressor associated with the proper compartment (similar to the
>adjustments 
>   made for unreliable transport).  Thus if the compartment is not reset by 
>   resetting the TCP connection, the next message will take advantage of the
>
>   adjustments."  
>  
>

Sounds like a reasonable approach. I've updated the text as you've 
suggested.

>Other minor comments:
>
>Page 8 section 3.1
>'Although the format of NACK messages are the same as the second variant of
>normal SigComp messages, it is useful to demonstrate the specific fields as
>they appear inside the "returned feedback item" field.'
>
>I think this is a relic of the NACK having once been the returned feedback
>item.  
>This sentence is not in line with either the text preceding it or the format
>of the NACK shown.
>
>Suggested text:
>"The format of the NACK message and the use of the fields within it are
>shown in Figure 1."
>  
>

Done.

>Page 12 number 21. ID_NOT_UNIQUE
>This section doesn't mention the details that go with this reason code
>(which are shown in Fig 2).
>
>Page 13 number 23. STATE_TOO_SHORT
>This section doesn't mention the details that go with this reason code
>(which are shown in Fig 2).
>
>  
>
Fixed.

>[Very minor:
>Page 14, 4.2 '... NACK message ...' is misssing an s.]
>  
>

Fixed. Thanks!

/a

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

---

From: Adam Roach <[email-masked]>
Date: Wed, 20 Oct 2004 18:06:10 -0500

[email-masked] wrote:

>----------
>Section 2.2:  
>  "For a connectionless transport, such as UDP, the NACK message is sent
>   back to the originator of the failed message at the port and IP
>   address from which the message was sent.  
>...
>
>      The behavior specified above is strictly necessary for any
>      generally useful form of a NACK mechanism.  In the most general
>      case, when an implementation receives a message that it cannot
>      decompress, it has exactly three useful pieces of information: the
>      contents of the message, an indication of why the message cannot
>      be decoded, and the IP address and port from which the message
>      originated.  Note that none of these contains any indication of
>      where the remote application is listening for messages, if it
>      differs from the sending port."
>
>This is true for the general case, but could be different in special cases. For example SIP uses the registration procedure, where the registrar may tell from the IP address where the user's listening port is. In that case it'd make more sense to send the NACK to the listening port.
>

The problem with allowing such an approach is that it falls apart except 
in the most narrowly constrained cases.

Consider the situation in which a SIP registrar has a registration that 
binds the AOR "sip:[email-masked]" to the contact 
"sip:[email-masked]:5060" and the AOR 
"sip:[email-masked]" to the contact 
"sip:[email-masked]:5070."

Now, that registrar sees a SigComp UDP packet arrive from port 62047 of 
the IP address 209.30.28.247. (I'm making the assumption that you can 
map that 209.30.28.247 back to the appropriate contacts, which can be a 
bit of a feat in itself, but we'll leave that alone for now). The 
message fails to decompress. It wants to send a NACK in response to it. 
Where does it go?

The answer is: you don't know. It might be from the client running on 
port 5060. It might be from the client running on port 5070. These 
clients might be for completely different users (e.g. they're going to a 
server with several X clients hanging off of it), and they're almost 
certainly different applications. How do you collect enough information 
to decide whether to send the NACK to 5060 or to 5070?

You can't.

That's precisely why we ended up making the NACK go back to the port 
from which it came. There's really no other way this can be made to work.

>Section 2.3.2:
>  "When a NACK is received for a message sent over a reliable transport,
>   initially be an attempt to reestablish the connection, and re-
>   initiate the failed transaction."
>
>Why should the SigComp layer always contact the application? If it acts as a shim layer couldn't it just silently retransmit the message with different parameters (just as TCP behaves on packet losses). It should only contact to the application, when there are unrecoverable errors (such as multiple NACKs after several attempts or TCP connection failure). And in particular it should be avoided that the application resets and reestablishes the TCP connection just because of a single NACK, for it is a rather time consuming procedure in large-delay networks.
>  
>

The original versions of the draft contained such language.

It was changed after someone -- in fact, looking through the archives, 
you -- suggested that this behavior was untenable. To quote you (message 
dated 10/30/2002):

>     Problem:
> Endpoints have to store SHA-1 hash and - in case of reliable transport 
> - the uncompressed version of ALL messages sent out. This is hardly 
> acceptable from the memory point of view on both sides. Moreover the 
> draft does not define when to release this data, since we have no ACK.
>
>     Possible solution:
> Allow endpoints to handle just a set of error codes (which are not 
> message specific). Thus it does not have to store anything, but is 
> still able to react to STATE_NOT_FOUND for example. The other errors 
> could trigger some default actions (like RESET). However, we lose the 
> retransmission possibilities in case of TCP this way.

You asked me to fix this, and I did. I'm not going to go back to the 
original behavior -- the one you called a problem two years ago -- this 
far into the process.

/a