RE: [Int-area] Lifting up a filter discussion from Monami6

"Narayanan, Vidya" <vidyan@qualcomm.com> Thu, 22 February 2007 06:08 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HK77n-0008Ke-Jm; Thu, 22 Feb 2007 01:08:15 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HK77l-0008KX-NH for int-area@ietf.org; Thu, 22 Feb 2007 01:08:13 -0500
Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HK77j-00010Z-9N for int-area@ietf.org; Thu, 22 Feb 2007 01:08:13 -0500
Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l1M686vS031154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 21 Feb 2007 22:08:07 -0800
Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l1M6869j012710; Wed, 21 Feb 2007 22:08:06 -0800 (PST)
Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Feb 2007 22:08:06 -0800
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Int-area] Lifting up a filter discussion from Monami6
Date: Wed, 21 Feb 2007 22:08:05 -0800
Message-ID: <C24CB51D5AA800449982D9BCB90325134F1B14@NAEX13.na.qualcomm.com>
In-Reply-To: <Pine.LNX.4.64.0702211208250.27444@netcore.fi>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Int-area] Lifting up a filter discussion from Monami6
Thread-Index: AcdVoVoYp5RlQDvfRViVQ2wRcfSQJwApNmsw
References: <45D307BE.4060903@piuha.net><C24CB51D5AA800449982D9BCB9032513464B13@NAEX13.na.qualcomm.com> <45D39688.5050200@levkowetz.com> <C24CB51D5AA800449982D9BCB9032513464B59@NAEX13.na.qualcomm.com> <45DAD041.5090003@ericsson.com> <C24CB51D5AA800449982D9BCB90325134F1990@NAEX13.na.qualcomm.com> <Pine.LNX.4.64.0702202044100.10161@netcore.fi> <C24CB51D5AA800449982D9BCB90325134F19F2@NAEX13.na.qualcomm.com> <Pine.LNX.4.64.0702211208250.27444@netcore.fi>
From: "Narayanan, Vidya" <vidyan@qualcomm.com>
To: Pekka Savola <pekkas@netcore.fi>
X-OriginalArrivalTime: 22 Feb 2007 06:08:06.0217 (UTC) FILETIME=[D1944390:01C75647]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Cc: Internet Area <int-area@ietf.org>
X-BeenThere: int-area@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/int-area>
List-Post: <mailto:int-area@lists.ietf.org>
List-Help: <mailto:int-area-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@lists.ietf.org?subject=subscribe>
Errors-To: int-area-bounces@lists.ietf.org

 

> -----Original Message-----
> From: Pekka Savola [mailto:pekkas@netcore.fi] 
> Sent: Wednesday, February 21, 2007 2:16 AM
> To: Narayanan, Vidya
> Cc: Magnus Westerlund; Internet Area
> Subject: RE: [Int-area] Lifting up a filter discussion from Monami6
> 
> On Tue, 20 Feb 2007, Narayanan, Vidya wrote:
> >> Maybe filter signalling is sufficiently more restricted case of 
> >> piggybacking arbitrary data that devising framing, PMTUD, 
> etc. for it 
> >> is simpler.  I might agree with that if the filters were 
> restricted 
> >> to be (say) less than 500 bytes so that no fragmentation was never 
> >> needed.
> >
> > Maybe I am missing something here, but, how does UDP help with 
> > fragmentation? The alternative proposed at the transport 
> layer seems 
> > to be UDP-based.
> 
> If a packet carries data or signalling from a single 
> application only, handling correct packetization of data that 
> application may wish to send is rather straightforward 
> because just one application needs to be concerned.
> 
> If a packet may carry data from multiple sources (e.g., 
> MIPv6, filters, even arbitrary applications) every one of 
> these will need to be involved and interact in the 
> packetization process.
> 
> However, the second case gets simpler if you'd use MTU=1280, 
> disable PMTUD, and fragment every packet that exceeds the MTU 
> without trying to optimize the payloads such that no 
> fragmentation was necessary.
> 
> Maybe this was the model you were suggesting and a reason for 
> the disconnect.
> 

Ah! Yes, I didn't think the payloads will be optimized to avoid
fragmentation. Also, I'm not sure if the filter rules in this case would
be handled as a separate application. Perhaps each application (MIP6 or
MOBIKE or SHIM6) that would carry the filter rules would have to handle
processing of the same? Ultimately, the filter rules are meant to be
used by one of these applications anyway. 

Vidya


> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> 

_______________________________________________
Int-area mailing list
Int-area@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/int-area