Subject: RE: [Softwires] Re: WG LC Problem Statement (Pekka Savola Comments)

From: "Durand, Alain" <[email-masked]>
Date: Thu, 5 Jan 2006 18:44:48 -0500

________________________________

From: [email-masked] on behalf of JORDI PALET MARTINEZ
Sent: Thu 1/5/2006 2:51 PM
To: [email-masked]
Subject: Re: [Softwires] Re: WG LC Problem Statement (Pekka Savola Comments)

Hi Alain,

Sorry miss this one before.

I disagree here. From my perspective is NOT an optimization, is something
really needed. Any solution MUST try first the simplest encapsulation.

==> Jordi, where is does this MUST come from? I remember the discussion with Karen from 3GPP a year
and a half ago where she was mentionning that even 3GPP could live with the always on 8 bit UDP encaps...

Do you have over hard data that will contradict this?

   - Alain.

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

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 06 Jan 2006 02:18:43 +0100

Hi Alain,

I respect what 3GPP could accept, but as an end user will not accept having
to pay extra packets which are not required.

IETF work is not to get happy vendors or other standard groups, but to
provide the best *balanced* solutions for the end of the chain (users).

Regards,
Jordi

> De: "Durand, Alain" <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Thu, 5 Jan 2006 18:44:48 -0500
> Para: <[email-masked]>, <[email-masked]>
> Conversación: [Softwires] Re:  WG LC Problem Statement (Pekka Savola Comments)
> Asunto: RE: [Softwires] Re:  WG LC Problem Statement (Pekka Savola Comments)
> 

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Barcelona 2005 Global IPv6 Summit
Slides available at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: David Ward <[email-masked]>
Date: Thu, 05 Jan 2006 22:40:04 -0600

Jordi -

I agree with your argument to conserve overhead theoretically and in the
architectural elegance of auto-detection but, what we see in practice is
that the most widely used tunneling technology does in fact mandate UDP.
Since it is so widely deployed and continues to have expanded deployment; it
clearly is acceptable to providers and end users. It is impractical and
unnecessary to put this requirement as a MUST.

Suggested sample text:

The tunneling protocol MUST be able to traverse NATs and it-would-be-nice if
they could (SHOULD if you prefer) be able to optionally not encapsulate in
UDP if not traversing a NAT ...

-DWard

On 1/5/06 7:18 PM, "JORDI PALET MARTINEZ" <[email-masked]>
wrote:

> This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the use of the
> individual(s) named above. If you are not the intended recipient be aware that
> any disclosure, copying, distribution or use of the contents of this
> information, including attached files, is prohibited.
> 
> 
> 
>

---

From: Francis Dupont <[email-masked]>
Date: Fri, 06 Jan 2006 09:22:49 +0100

I believe we are using a bad definition of simplicity, i.e., it is not
so important to have the smallest possible encapsulation but the
simplest protocol to setup and operate. So as in some circumstances
(multihoming or mobility) it is far easier to always use UDP than
to dynamically detect NATs, I support Alain's proposal but not Jordi's
one.

Regards

[email-masked]

PS: IMHO the best is to do like IPsec NAT traversal: optional NAT detection
at the setup as the default policy.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 06 Jan 2006 10:10:20 +0100

Hi David,

I don't agree with your statement here. The most widely used tunneling
technology may be UDP when there is a NAT that can't be traversed, but there
are lots of situations where that is not true.

My fear is that not requiring that auto-detection will create some products
in the market that miss that "elegance" that you also agree with. That will
create interoperability inefficiencies, in the sense that you can find an
implementation of the client that supports it and a concentrator that
doesn't support it, or in the other way around.

If the implementation cost of the audo-detection is very high (and extra
cost from the implementers point of view), I will understand that, but
that's something done already, and there is a lot of code there to check
that, so there is no any extra cost just using it and in that case, I think
is a good balance to make it a requirement versus the overhead being saved.

Also, if we don't require the auto-detection, there is no reason to require
IPv6-in-IPv4 support, is a kind of inconsistency.

Regarding your proposed text, it will not be correct the last part "if not
traversing NAT", because as described in draft-palet-v6ops-proto-41-nat
(expired, need to update it ASAP I can), you can have a NAT box and still
use IPv6-in-IPv4.

Regards,
Jordi

> De: David Ward <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Thu, 05 Jan 2006 22:40:04 -0600
> Para: <[email-masked]>, "[email-masked]" <[email-masked]>,
> "Durand, Alain" <[email-masked]>, David Ward <[email-masked]>
> Asunto: Re: [Softwires] Re:  WG LC Problem Statement (Pekka Savola Comments)
> 
> Jordi -
>

---

From: Laurent Toutain <[email-masked]>
Date: Fri, 6 Jan 2006 15:15:38 +0100

I also disagree with Jordi, we don't care about the overhead of  
tunneling,
if you want to reduce overhead for tunneling on the radio interface  
(and it
is a case not just for transition, but mobility has the same problem)  
you have
ROHC protocol and extensions.

For softwire, we need a simple solution that works in any case. My  
experience
with tunneling is that it is more important to work on a good MTU  
negotiation
than focus on the little amount of bit we are loosing with  
encapsulation.

Laurent

> doesn't support it, or in the other way around.

The goal of the working group is not to specify a profile to guaranty
interoperability ?

>>>> Conversación: [Softwires] Re:  WG LC Problem Statement (Pekka  
>>>> Savola
>>>> Comments)
>>>> ==> Jordi, where is does this MUST come from? I remember the  
>>>> discussion with
>>>> Karen from 3GPP a year
>>>> and a half ago where she was mentionning that even 3GPP could  
>>>> live with the
>>>> always on 8 bit UDP encaps...
>>>>
>>> individual(s) named above. If you are not the intended recipient  
>>> be aware
>>> that
> This electronic message contains information which may be  
> privileged or confidential. The information is intended to be for  
> the use of the individual(s) named above. If you are not the  
> intended recipient be aware that any disclosure, copying,  
> distribution or use of the contents of this information, including  
> attached files, is prohibited.
>
>
>
>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 06 Jan 2006 15:44:13 +0100

Hi Laurent,

The point is not just the unnecessary overhead of the encapsulation, but
also the additional keep alive messages that you need. I agree on using
ROHC, of course, but this doesn't help to avoid extra keepalive messages
that aren't needed if you can use IPv6-in-IPv4 instead of
IPv6-in-UDP-in-IPv4.

By the way, what you mention is something that we have not considered as
part of the requirements:
1) Support for ROHC
2) MTU negotiation

I think will be important to add some text about each of those points. I'm
not familiar with ROHC, there are any special requirements for being able to
support it (in both cases, when the network is IPv4-only or when it is
IPv6-only) ?

Regards,
Jordi

> De: Laurent Toutain <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Fri, 6 Jan 2006 15:15:38 +0100
> Para: <[email-masked]>
> CC: "[email-masked]" <[email-masked]>
>>>> privileged or

---

From: David Ward <[email-masked]>
Date: Fri, 06 Jan 2006 10:44:50 -0600

Jordi -

Since the main goal of finding our first solution is to include TTM as a
heavily weighted variable, it is still not reasonable to place a strict
requirement for auto-detection when deployments are not mandating it.
Whether the issue is header overhead, keepalives, etc it is clearly
acceptable today. For the first phase solution we agreed that we had to
"chuck" out the verbiage that Laurent is mentioning of strict "setup
overhead" requirements because for the first phase, it isn't necessary. To
that end, things we would like (and I agree w/ the _desire_ to include
auto-detection) and things we must have, have to be separated due to the
pragmatics of TTM. My suggestion of "MUST be able to traverse NAT ...
SHOULD|would-be-nice-to be able to auto-negotiate..." is still the
recommended verbiage given the meta-goals we have given ourselves.

-DWard

On 1/6/06 3:10 AM, "JORDI PALET MARTINEZ" <[email-masked]>
wrote:

>>>> ==> Jordi, where is does this MUST come from? I remember the discussion
>>>> with
>>>> Karen from 3GPP a year

---

From: Tim Chown <[email-masked]>
Date: Tue, 17 Jan 2006 16:01:58 +0000

> UDP if not traversing a NAT ...

[Sorry I've come to the discussion late, had a wee disaster at our site which
 we're only just emerging from]

I feel that optimisation should not be prioritised.  The softwire solution
should focus on interoperability, and assume that it is an interim, short
term solution towards a native IPv6 deployment?  Providers may be less 
inclined to migrate from an optimised softwire solution to a native solution?

Tim