Subject: RE: [rohc] "returned feedback item" in NACK

From: "Surtees, Abigail" <[email-masked]>
Date: Mon, 20 Mar 2006 16:45:40 -0000

Hi Adam, Cristian, 

I can see that the feedback from msg 1 would be useful, but doesn't this
bring us back to Cristian's original question?  How does endpoint B know
which compartment msg2 was for (and so which compartment to send
feedback for)?  Decompression must have failed (otherwise you wouldn't
be sending a NACK) so msg2 doesn't get given to the application for
compartment identification.

Or am I missing something?

Best regards,

Abbie

> 
> It wasn't really my idea; if I recall correctly, it was Richard Price 
> who wanted the returned feedback portion to be available for returned 
> feedback. In fact, in early versions of the NACK draft, the 
> NACK details 
> were in the returned feedback portion of the message, which make 
> returned feedback in a NACK message impossible.
> 
> I think the use-case that Richard described was something along the 
> lines of:
> 
>    A              B
>    |--- MSG 1 --->|
>    |--- MSG 2 --->|
>    |<--- NACK ----|
> 
> In this case, MSG 1 decompresses successfully and creates a returned 
> feedback object. MSG 2 fails to decompress and triggers a 
> NACK. I think 
> it would be legal (and potentially even useful) for this NACK 
> message to 
> contain the requested feedback that was created by MSG 1.
> 
> /a
> 

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

---

From: Adam Roach <[email-masked]>
Date: Wed, 22 Mar 2006 11:33:21 -0600

Abigail and Richard Price had a brief exchange on this topic. Richard
originally suggested the changes that led to the NACK format published
in RFC 4077.

For the benefit of those interested in the original logic for historical
reasons, I'm copying Richard's explanation here:

>As far as I can remember, you can only send positive feedback inside a NACK when you're using a transport-based mechanism to determine compartments (i.e. a mechanism that doesn't need the contents of an application message to assign compartments - assigning them based on IPSec or TLS associations is the example that springs to mind).
>
>Suppose you've got some feedback ready to send from a valid msg 1 (for which you know the compartment), and later get a dodgy msg 2 which fails to decompress. You decide to return a NACK for the dodgy message. If your mechanism for identifying compartments relies on info from an application message then you won't be able to return the feedback inside the NACK, since you don't have an application message in the first place. However, if you're using a transport-based mechanism to identify compartments (TLS associations or whatever) then it's ok to return the feedback item in the NACK.
>
> ...
>
> Technically you don't need to identify the compartment of the failed
> message since it won't generate any feedback (rather, the feedback
> comes from an older valid message). Instead you need to identify the
> compartment of the older valid message (easy) and the compartment of
> the NACK. But in practice this amounts to the same thing, as you can
> only identify the compartment of the NACK if you're using a
> transport-based mechanism that doesn't care about the contents of the
> application messages.
>
>...
>
>I suspect that no-one will actually bother combining the two in practice, but on the other hand the option of sending feedback data inside a NACK doesn't do any harm even if it never gets used. I also marginally prefer the final NACK message layout to the earlier one, as earlier versions put the NACK data in the same place as the feedback item, which meant that you had to read the code_len field to determine whether you have a NACK, and then go backwards to find out what the NACK data actually is. The final message layout makes the parsing more intuitive, which is probably a stronger argument for it than any slim chance of combining the two types of feedback data  ;-) 
>

/a

---

From: Cristian CONSTANTIN <[email-masked]>
Date: Wed, 22 Mar 2006 19:33:42 +0100

> >I suspect that no-one will actually bother combining the two in practice, but on the other hand the option of sending feedback data inside a NACK doesn't do any harm even if it never gets used. I…

cristian: o.k. thanks. 

anyway, I do not find the parsing of the sigcomp message at all intuitive but 
rather cumbersome (i.e. fields with offsets which depend on some previous 
parsed field determine the type of the packet...) 

on the other hand there is an interesting explanation after all for a feedback
entry in the NACK message which gives some hints on when such a feedback
can appear.

thanks again.
bye now!
cristian
-- 
 _          | There are many people who use UNIX or Linux  
(_'_        | who IMHO do not understand UNIX.
  (_'rist   |              --David Korn  
GPG public key at wwwkeys.de.pgp.net
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: Cristian CONSTANTIN <[email-masked]>
Date: Thu, 23 Mar 2006 00:00:46 +0100

> >Suppose you've got some feedback ready to send from a valid msg 1 (for which you know the compartment), and later get a dodgy msg 2 which fails to decompress. You decide to return a NACK for the d…

cristian: my impression is that the both devices communicating with
each other with sigcomp (say a mobile IMS terminal on one side and an
P-CSCF on the other) have to agree somehow on this compartment mapping
(i.e. on the TCP connection for example). now, could you please tell me
how is this agreement performed?

what I'm trying to say is that is usless that the P-CSCF does this kind
of mapping but the mobile terminal has no idea about it...

bye now!
cristian

---

From: iPekka Pessi <[email-masked]>
Date: Thu, 30 Mar 2006 20:15:56 +0300

>how is this agreement performed?

The compartment should map to (set of) security association
between IMS and terminal. TS 24.229 V6.5.1 which happen to lay on
my hard disk is quite vague on the matter. However, idea is that
you have two security associations, one for UDP, another for TCP,
and my guess is that they should both map to same compartment. 

v6.5.1 also gives minimum of 8K for dms and 4K for sms. Before
V6.5 there was no mention of dms or sms, so I'm afraid that with
3GPP rel5 IMS you are on your own. I have a vague feeling that
Nokia rel5 IMS offers 4K for both dms and sms.

>of mapping but the mobile terminal has no idea about it...

;-/

--Pekka

---

From: Cristian CONSTANTIN <[email-masked]>
Date: Fri, 31 Mar 2006 11:56:26 +0200

> Nokia rel5 IMS offers 4K for both dms and sms.

cristian: hi pekka and thanks a lot. 
I have been browsing yesterday a lot of this documents with no success...
now I know where I should look for this default IMS values/settings.

on the other hand is dynamic (deflate) compression/decompression really
working with a 4k dms? I'm taking into account that
dms=udvm_memory_size+sigcomp_message_size (udp) or even worse, for tcp
the udvm gets half the dms; and let us not forget the size of the IMS
signalling packets...

bye now!
cristian