Subject: RE: [v6tc] Issue 1: Could we live with UDP encapsulation always o n?

From: "Karen E. Nielsen (AH/LMD)" <[email-masked]>
Date: Wed, 22 Dec 2004 15:22:27 +0100

Hi - 

Alain has asked me to sent this to the list.

For what it's worth.....

In what concerns Ipv6-UDP-IPv4 opposed to Ipv6-Ipv4,
there are at least 3 things to consider:
- radio overhead
- compression mechanisms
- implementation aspects

Radio link overhead:
Obviously radio people always want to have the smallest overhead possible.
Having said that then in the worst case VoIP scenarios, that is,
lots of packets of 44 bytes payload, this on the radio link results in 
a difference of packet sizes:

With UDP encapsulation, 44 bytes of payload -->
Packet size on radio:
44+8+20+8+40 + 12(link overhead) = 124

Without UDP encapsulation, 44 bytes of payload -->
Packet size on radio
44+8+20+40 + 12(link overhead) = 116

Thus all in all an worst case excess in 7% in radio resource 
consumption.

Compression mechanisms (e.g. ROCH):
Should be investigated. 

Implementation aspects:
I absolutely assume that we are talking about UDP-lite (no checksum 
calculations)

>From an implementation aspects, I don't really like the 
UDP encapsulation (but it can be done of course).

In routers (here tunnel servers) the next header value often
determines whether the packet is sent to the control plane for higher layer processing. 
With UDP encapsulation either
an additional UDP filtering step must be implemented in the forwarding 
plane or the packets will be sent
to slow path processing. Neither of these alternatives are really 
promising (either they result in bad performance or in excessive development costs).

In hosts the problem is probably not as bad performance wise. But it still 
complies badly with modular implementations, i.e. user plane higher layer processing 
opposed to kernel space interface processing.

The stateful aspect is not good, but scalability wise it may not 
perform any worse than a MIP Home Agent. The business case for making
high performance Home Agents may be much better than the corresponding one
for transition mechanisms, though.

Semi-conclusion:
Now worst case 7% "waste" of radio resources 
is certainly not negligible business wise, but it should 
not be a showstopper. This especially given that the bandwidths 
of the radio links are ever increasing AND that preferably only a small
portion of the traffic over the link will be tunnelling traffic. 
Personally, I am much more concerned
with the implementation aspects in end-nodes and routers.

I cannot say that any of this is show-stopper candidates, but all in all
it doesn't make v6-udp-v4 seem very attractive 
compared to v6-in-v4 the mechanisms we work with today.
 
BR, Karen

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

---

From: Pekka Savola <[email-masked]>
Date: Wed, 22 Dec 2004 17:00:02 +0200 (EET)

> promising (either they result in bad performance or in excessive development costs).

I'm not sure if I understand what you're saying.

Whether or not the router should process the packet depends on the 
destination address or if it has router alert hop-by-hop option.

Or are you referring to router implementations which perform 
IPv6-in-IPv4 in hardware (without control plane), but could not do the 
same to IPv6-in-IPv4[UDP] ?

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

---

From: Ole Troan <[email-masked]>
Date: Wed, 22 Dec 2004 15:23:13 +0000

> same to IPv6-in-IPv4[UDP] ?

I don't see the implementation problem here either. the packets are
already channelled off on a branch since those packets are for the
router itself. I don't see a big difference in doing IPv6/UDP over
IPv4 versus e.g IPv6/GRE over IPv4.

/ot