Subject: [Mip4] draft-vaarala-mip4-optudp-00

From: [email-masked]
Date: Tue, 10 Feb 2004 14:46:00 +0200 (EET)

Hi,

Here's a small strawman draft regarding MIPv4 overhead optimization:

  http://www.ietf.org/internet-drafts/draft-vaarala-mip4-optudp-00.txt

The draft applies when the MN sends most of its traffic to
*one* particular CN, in which case overhead to that particular
CN can be optimized.  The mechanism applies at least to the
case where MIPv4 provides mobility for IPsec tunneling - 
e.g. the normal IPsec-over-MIPv4 situation.  It might also
apply to some VoIP scenarios.

Has anyone else been working on overhead optimizations?
I'm sure all vendors have heard of the "overhead issue" :-)

The abstract of the draft is as follows:

   This document specifies an extension to Mobile IPv4 UDP encapsulation
   (RFC 3519) which enables optimization of overhead when UDP
   encapsulation is used, and most of the mobile node's data traffic is
   destined to one particular correspondent node.

Any feedback appreciated,

-Sami

-- 
Mip4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mip4

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 10 Feb 2004 14:38:45 +0100

Hi Sami,

> apply to some VoIP scenarios.

Quite interesting, and still straightforward.  Comments after a swift
read-through:

In section 2.3, Optimized UDP Tunnel Reply Extension, I think it would
be good to have an explicit flag to indicate acceptance or rejection of
optimized tunnelling, rather than letting presence/ absence of the
extension itself indicate this.  To support legacy HAs you still need to
handle absence as a no to optimization, though. Having an explicit flag
is 1) cleaner, and 2) if there in the future would be more than one
optimization possibilities, it would be nice if a HA could indicate that
Yes, it understands optimization, but No, it won't accept the particular
one proposed in the RRQ.

In section 5, Security Considerations, it is not immediately obvious to
me what you mean when you say the "inner" IPv4 header can be easily
tampered with - in the optimized case there is no inner IPv4 header, no?

In section 6, Alternatives,
	New message type - I don't see any benefit from this

	Multiple preferred CNs - possible, but should maybe be
		left as a later exercise, once there is some
		experience with this implementation? In that
		case, an index into a list of CNs would be more
		appropriate than a set of bits, though.

	FA support - Mixed feelings.  It's needed in order to be
		a complete solution, at the same time as FA
		deployment seems to be negligible.

	Best,
		Henrik

---

From: [email-masked]
Date: Tue, 10 Feb 2004 16:13:56 +0200

Hi, 

> [...]

I agree.  So we'd either need to have (a) a flags field (perhaps in
both RRQ and RRP extensions) or (b) a reply code field.  We added a
reply code in the NAT reply, but only needed a single error code after
all.  Which do you prefer?  (I'd rather go with the flag.) 

> tampered with - in the optimized case there is no inner IPv4 header, no?

Right, that's just bad wording.  The intent is to say that in normal
MIPv4 one can easily tamper with the inner header, i.e. the one which
results after decapsulation.  Similarly here, by tampering with the
"outer" (the only) IP header, you can tamper with the "inner" header,
i.e. the one resulting after decapsulation. 

Best, 

 -Sami

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 10 Feb 2004 15:57:41 +0100

Hi Sami,

> all.  Which do you prefer?  (I'd rather go with the flag.) 

In this case I think I'd go with a flag, too.

> results after decapsulation.  

Yes.

> Similarly here, by tampering with the

Yes, but actually to a slightly lesser extent - the expanded inner
header source and destination can't be tampered with, nor can protocol,
while you're right for most of the other fields (length, tos, id, flags,
ttl).  No?

	Henrik

	Henrik

-- 
  Those are my principles. If you don't like them, I have others.
    -- Groucho Marx