Subject: [dispatch] Draft new: draft-sunil-sankar-dispatch-sip-incr-00.txt

From: "Sunil Kumar Sinha -X (sunsinha - SCARLET WIRELESS INDIA PRIVATE LIMITED at Cisco)" <[email-masked]>
Date: Mon, 13 Jun 2016 17:02:25 +0000

Hi,

We've submitted a new draft, draft-sunil-sankar-dispatch-sip-incr-00.txt.

The purpose of the draft is to register a new optional tag called "incr" as an extension for the SIP Message indicating that only those header(s) will be present in the subsequent request or response whose attribute is changed. This is necessary to increase the processing speed of any proxy server and also prevents fragmentation of messages over UDP and provides congestion

Regards,

Sunil Sinha

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 13 Jun 2016 17:32:49 +0000

Hi,

In my experience, there aren't many "unnecessary" headers in mid-dialog requests. But, if you think there are, some examples would be useful.

Also, just because header values don't change, it doesn't mean they aren't needed, in order to maintain state. For example, the Route headers are needed in case there are call-stateless proxies along the path.

Regards,

Christer

From: dispatch [mailto:[email-masked]] On Behalf Of Sunil Kumar Sinha -X (sunsinha - SCARLET WIRELESS INDIA PRIVATE LIMITED at Cisco)
Sent: 13 June 2016 20:02
To: [email-masked]; [email-masked]
Cc: Sankar Raman V -X (sramanv - SCARLET WIRELESS INDIA PRIVATE LIMITED at Cisco) <[email-masked]>
Subject: [dispatch] Draft new: draft-sunil-sankar-dispatch-sip-incr-00.txt

Hi,

Regards,

Sunil Sinha

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 13 Jun 2016 13:52:05 -0400

"Sunil Kumar Sinha -X (sunsinha - SCARLET WIRELESS INDIA PRIVATE LIMITED
at Cisco)" <[email-masked]> writes:
> The purpose of the draft is to register a new optional tag called
> "incr" as an extension for the SIP Message indicating that only those
> header(s) will be present in the subsequent request or response whose
> attribute is changed. This is necessary to increase the processing
> speed of any proxy server and also prevents fragmentation of messages
> over UDP and provides congestion

It's not clear to me how valuable this would be.  The bandwidth needs of
calls are dominated by the media, not the signaling, so compressing the
signaling is not particularly useful.  If the signaling travels a
different path, then there might be some benefit.

It's not clear to me how the mechanism would work.  An example would be
very helpful.  In particular, how does it handle the case when a header
"Header: value" appears in message 1 and then the "Header" does *not*
appear in message 2 -- as described by the draft, there's no way to
designate "'Header' is not present" if the previous message contained
'Header'.  Or is the mechanism dependent on no header having an empty
value?

Unless you require all proxies to be dialog-stateful, then you have to
make sure that headers that must be inspected by proxies are exempted
from incremental processing.  The draft doesn't seem to be clear about
which headers are exempted.  It provides the list To, From, CSeq,
Call-ID, Max-Forwards and Via, but among them, only Max-Forwards must be
examined by proxies.  However, Proxy-Require must be examined by proxies
but is not included in the list.

What happens when a message from one UA to another is completely lost?
If the UAS does not receive request CSeq 2, then it has no way of
reversing the incremental encoding of request CSeq 3.

How does this mechanism compare in practice to SigComp (RFC 3320 etc.)?
A web search suggests that SigComp is used in IMS, so there should be
solid information on the use of SigComp in practice.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 13 Jun 2016 14:21:42 -0400

As others have already asked, I would like to see some specific examples 
of how you see this being useful.

IIUC, this proposal is intended to apply within a dialog. I think it 
implies a change in what constitutes dialog state, adding a number of 
new items to the state - namely the value of all the header fields in 
every message transmitted within the dialog. That is a very large 
change, even if it is only required of those supporting the option.

Also as has been mentioned, some fields in messages are used by proxies. 
They don't have a say in the option negotiation, but they will be 
impacted if it is negotiated. To avoid this you would need to 
Proxy-Require the option to verify that all proxies can handle it. And 
this would severely limit the applicability of the feature.

As already noted, sip messages typically make a negligible contribution 
to the overall bandwidth used by a session, so I don't consider than a 
useful justification. And reducing message size to avoid fragmentation 
is only helpful if it is always used. When this is an optional feature 
you still have to design your application to work when it isn't used. 
And many other factors continue to increase the likely size of sip 
messages so that solutions that work with large messages are needed. 
Trying to keep messages within a PDU is probably futile.

Is there some reason other than message size to motivate this?

	Thanks,
	Paul

On 6/13/16 1:02 PM, Sunil Kumar Sinha -X (sunsinha - SCARLET WIRELESS 
INDIA PRIVATE LIMITED at Cisco) wrote:
> Hi,
>
>
>
> We’ve submitted a new draft, draft-sunil-sankar-dispatch-sip-incr-00.txt.
>
>
>
> The purpose of the draft is to register a new optional tag called "incr"
> as an extension for the SIP Message indicating that only those header(s)
> will be present in the subsequent request or response whose attribute is
> changed. This is necessary to increase the processing speed of any proxy
> server and also prevents fragmentation of messages over UDP and provides
> congestion
>
>
>
> Regards,
>
> Sunil Sinha
>
>
>
>
>
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>