RE: [rohc] Constant IP-ID in the RTP Profile(0x0001)

["Kristofer Sandlund" <[e-mail]>]

Biplab,

> I think, if we can ignore the "transparency" criteria

that's a big "if" and I don't see a case where that it would be legal
to assume you can. Sure, you can probably get away with it on most
occasions, but what's to say that the endpoint doesn't have some type
of integrity check that the packet is not modified (e.g. if this
is a tunneled header and the tunnel carries integrity protection over
the inner header + payload, in which case you destroy the entire flow by
modifying the IP-ID). The above is just an example which may or may not
be very realistic, but the principle definitely is the following:
    As a "middlebox", the compressor isn't allowed to make assumptions
    on what the endpoint might do with the traffic.

And besides, do you really think that a potential gain of 2 octets is
worth breaking transparency? I say that would be bad practice.

/Kristofer

Biplab Sarkar <mailto:[e-mail]> wrote on den 3
januari 2008 13:27 :

> * PGP Signed by an unknown key: 01/03/2008 at 01:26:30 PM
> 
> Hi Kristofer,
> 
> Thanks for the recommendation.
> 
> I think, if we can ignore the "transparency" criteria, we can
> set IP-ID to RTP-SN and DF=1  (RFC791) and compress it using
> ROHC. At the peer end, seeing DF=1 will suggest the packet is
> not a fragmented packet so IP-ID is not "well-defined" for
> that case. The IP-ID should be ignored. Its just a way to
> force the receiver to ignore the IP-ID field.
> 
> It might help in a lot of situations.
> 
> Thanks & Regards
> Biplab Sarkar
> 
> 
> On Thu, 2008-01-03 at 13:01 +0100, Kristofer Sandlund wrote:
> 
> 
> 	Biplab,
> 
> 	I would not recommend such a behavior since that break
compression
> 	transparency, which is bad. You can't just assume that
> the endpoint
> 	does ignore the IP-ID although that is the likely behavior.
> 	For 3095-based profiles, a zero IP-ID should be
> compressed using RND=1.
> 
> 	/Kristofer
> 
> 	Biplab Sarkar <mailto:[e-mail]>
> wrote on den 3
> 	januari 2008 12:48 :
> 
> 	> > Old Signed by an unknown key: 01/03/2008 at 12:47:59 PM
>
> 	> Hi Gangadharan,
> 	>
> 	> IP-ID can be over-written with the value of RTP-SN at the
> 	> compressor before compression for all "un-fragmented" IPv4
> 	> packets. This will enhance the compression.  Since IP-ID is
> 	> used in IP fragmentation, we can basically ignore its real
> 	> value for "un-fragmented" IP packets.
> 	>
> 	> Thanks & Regards,
> 	> Biplab Sarkar
> 	>
> 	> On Thu, 2008-01-03 at 17:07 +0530, Gangadharan G,
> TLS-Chennai wrote:
> 	>
> 	> 	Hi All,
> 	>
> 	>
> 	>
> 	> 	In the Linux Suse 10.1 machine, the value of the IP-ID
> 	> in the IPv4 header is always zero (i.e., constant) in the
>
> 	entire IP datagrams. >
> 	> 	The IP-ID Encoding, as per RFC 3095, of the RTP profile
> 	> doesn't handle this case (constant IP-ID).
> 	>
> 	>
> 	>
> 	> 	Also this issue had been discussed in the mailing list.
>
> 	>
> http://www1.ietf.org/mail-archive/web/rohc/current/msg01502.html
>
> 	>
> 	>
> 	> 	When I searched in the Internet, I found few proposed
> 	> solutions (yet to read them).
> 	>
> 	>
> 	> (draft-ietf-rohc-rfc3095bis-improvements-03.txt,
> 	> draft-kapoor-rohc-rtp-new-requirements-00.txt
> 	> <http://www.potaroo.net/ietf/idref/draft-kapoor-rohc-rtp-new-r
> 
> equirements/rfcmarkup?repository=/away/ietf&url=/away/ietf/all
> 	-ids/draft 	-> kapoor-rohc-rtp-new-requirements-00.txt> ,
> 	>
> 	> 	 RFC 3643 -- A Compression Profile for IP)
> 	>
> 	>
> 	>
> 	> 	Please let me know the solution/standard that everyone
> 	> is following for this issue in the RTP Profile.
> 	>
> 	>
> 	>
> 	> 	Thanks,
> 	>
> 	> 	Gangadharan
> 	>
> 	>
> 	>
> 	>
> 	> DISCLAIMER:
> 	> --------------------------------------------------------------
> 	> ---------------------------------------------------------
>
> 	> The contents of this e-mail and any attachment(s) are
> 	> confidential and intended for the named recipient(s) only.
> 	> It shall not attach any liability on the originator or HCL or
> 	> its affiliates. Any views or opinions presented in
> 	> this email are solely those of the author and may not
> 	> necessarily reflect the opinions of HCL or its affiliates.
> 	> Any form of reproduction, dissemination, copying, disclosure,
> 	> modification, distribution and / or publication of
> 	> this message without the prior written consent of the author
> 	> of this e-mail is strictly prohibited. If you have
> 	> received this email in error please delete it and notify the
> 	> sender immediately. Before opening any mail and
> 	> attachments please check them for viruses and defect.
>
> 	> --------------------------------------------------------------
> 	> ---------------------------------------------------------
>
> 	>
> 	>
> 	> 	_______________________________________________
> 	Rohc mailing
> 	list > 	[e-mail]
> 	> 	https://www1.ietf.org/mailman/listinfo/rohc
> 	>
> 	> * Unknown Key
> 	> * 0x6D543EEE (L)
> 
> * Unknown Key
> * 0x6D543EEE

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