Subject: Re: [tsvwg] Generic UDP tunneling (draft-manner-tsvwg-gut-00)

From: Bob Briscoe <[email-masked]>
Date: Wed, 03 Feb 2010 12:13:37 +0000

Jukka,

I'm about to send a review of your (& Nuutti's) GUT draft. But some 
of my review relates to Pasi's points in the old thread below. So 
I'll rekindle it, inline...

At 05:59 01/10/2009, Jukka Manner wrote:
>Hi Pasi,
>
>Thanks for the comments, some late replies below.
>
>cheers,
>Jukka
>
>Pasi Sarolahti wrote:
>>Hi Jukka,
>>I had discussed about a generic UDP tunneling scheme with a few 
>>IETF colleagues (including you) a couple of months ago, but the 
>>draft I started to write then got forgotten in my drawer.
>>Of course there is the main tussle aspect about whether starting to 
>>encapsulate protocols generally inside UDP in hopes of better 
>>middlebox traversal is the right step from the standardization 
>>viewpoint (as discussed in earlier BOFs and plenaries, I guess). 
>>Putting that question aside, here are some technical thoughts:
>
>Yes, you are right, whether creating some generic UDP tunnelling is a
>valid goal would need some wide discussion within the community - I
>don't recall what the end resul has been so far, probably against 
>it. My quick-and-dirty draft and spec just wanted to trigger some 
>discussion at least by making one proposal in that direction. The 
>fact still remains, a lot of protocols do not get through NATs or 
>firelwalls, and this harms progress.

There are two reasons new protocols can't be deployed:
i) deliberate: the above tussle where "new = potentially dangerous"
ii) accidental: lazy middlebox designs that don't take account of evolvability

GUT allows (i) to still play out as before.
But at least it aims to remove (ii).

You might want to say this in the draft.

>>I'm a little doubtful about the idea of using a single UDP port for 
>>all protocols. The receiver of the UDP datagrams would need to 
>>carry out the de-multiplexing and forwarding to different protocol 
>>modules and manage the related state, which could as well be done 
>>"automatically" by the UDP implementatation, by using different 
>>port numbers for each protocol.

Pasi, what's the real problem you see?

For me, the problem is that we are having to create a whole sub-layer 
just to get back to where we were before badly designed NATs were 
deployed. But if that's the best we can do, we need to grasp the nettle.

>For the multplexing, the implementation we have is very simple: at the
>receiver, you just get the packet, remove the GUT header, reattach 
>the IP header, calculate a possible checksum if the encapsulated 
>protocol has one, and give the packet to the IP stack. The stack 
>then handles the
>protocols by itself as if it came from the interface directly, the 
>GUT implementation does not need to care about the local IP stack 
>processing after it has rebuilt the original packet. Our 
>implementation on Linux is  only a few hundred lines of code, need 
>to check, but it was quite little (without the fragmentation and IP 
>option handling).
>
>>We had discussed a couple of ways for doing this:
>>1) simply allocate the needed range of UDP ports from IANA for 
>>different protocols (which might be wasteful), or
>>2) (in my opinion) more elegantly, have a separate initiation 
>>phase: first, a client sends a message to a well-known UDP port and 
>>asks what is the UDP port number for tunneling protocol X. If the 
>>client gets a positive response, it can start sending UDP-tunneled 
>>protocol packets directly to the returned port Y without additional 
>>GUT header overhead. In such system it would be easy to add new 
>>protocols for experimentation, for example just by adding new 
>>entries in a configuration file processed by a small application 
>>that listens to the queries at a well-known UDP port and responds 
>>by returning the port numbers for tunneling the configured protocols.
>
>Of these two, I'd take the latter. It sounds pretty okey to me. You 
>could as well send the first encapsulated packet to GUT and have a 
>control message saying that subsequent packets should be sent to 
>port P from now on.

I prefer something like the GUT approach to both of these. The choice 
is between:
1) wasting port numbers
2) wasting round trop times
GUT) wasting header bandwidth

For me, avoiding RTTs is the most important thing for a datagram 
service. It needs to get started with minimum delay. The first 
datagram may be the only one, but fast start is still important even 
if it might be supporting connection-oriented services above it like 
DCCP or SCTP. Short flows are where all the value is on the Internet, 
so we don't need extra RTTs to get started. Then we might as well 
have used ATM.

Building in an unnecessary extra RTT delay should only be 
contemplated if no other way will ever be possible.

>>In any of the above cases, a strong advise should be given to first 
>>try if the native protocol works without UDP encapsulation, before 
>>going into UDP tunneling mode.
>
>Naturally this is the way to go. A scheme like GUT could monitor the 
>original protocol and if a connection does not seem to materialize, 
>try UDP tunneling automagically.

An implementation could try both native & GUT in parallel (perhaps 
heuristically if it has found that every time it doesn't use GUT for 
certain protocols, it gets no response - i.e. the blackhole is 
probably its own NAT).

>>Other issue: I don't get the usefulness of the magic number. If a 
>>well-known port is allocated by IANA, it should be safe to assume 
>>it is used for this purpose. If there are malformed packets, for 
>>example from some older app that doesn't know GUT, they would 
>>likely be rejected at some point in the processing, because the 
>>content would not match any protocol state (or checksum 
>>calculation) of the inner protocol.
>
>This concept was taken from GIST where we use a magic number for 
>this exact purpose, verify that the packet truly (at some level of 
>confidence) is a GIST packet. You could live without it, sure, but 
>you can run into problems later due to unnecessary packet processing.

I also would prefer GUT without the magic number. See my full review for why.

Cheers

Bob

>>- Pasi
>>
>>On Sep 14, 2009, at 7:16 AM, Jukka MJ Manner wrote:
>>
>>>Dear all,
>>>
>>>We submitted the following draft and would appreciate feedback and 
>>>comments from the community.
>>>
>>>The spec is not purely a pen and paper exercise, we have a Linux 
>>>implementation that indicates that the concept works quite nicely, 
>>>at least with the hardware we tried it with (Linux end hosts, some 
>>>out-of-the-box D-link and Linksys NAT boxes in between). We need 
>>>to fix and add a few things, then we can release the 
>>>implementation as open source.
>>>
>>>http://www.ietf.org/id/draft-manner-tsvwg-gut-00.txt
>>>
>>>cheers,
>>>Jukka
>>>
>>>-------------------------------
>>>
>>>A new version of I-D, draft-manner-tsvwg-gut-00.txt has been 
>>>successfuly submitted by Jukka Manner and posted to the IETF repository.
>>>
>>>Filename:     draft-manner-tsvwg-gut
>>>Revision:     00
>>>Title:         Generic UDP Tunnelling (GUT)
>>>Creation_date:     2009-09-14
>>>WG ID:         Independent Submission
>>>Number_of_pages: 12
>>>
>>>Abstract:
>>>Deploying new transport protocols on the Internet is a well-known
>>>problem, as NATs and firewall drop packets with new protocol types.
>>>Tunnelling over UDP is one way to make IP packets hide the actual
>>>payload and enable end-to-end delivery.  This draft proposes a simple
>>>UDP tunnelling encapsulation and end-host operation to enable new IP
>>>payloads, e.g., new transport protocols, to be deployed on the
>>>Internet.
>

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: Jukka Manner <[email-masked]>
Date: Wed, 03 Feb 2010 16:40:36 +0200

Hi Bob, thanks for the feedback. Just one answer for you comment below, 
about the reasons a new protocol can't be deployed: yes, GUT tackles the 
first one, i.e., old/lazy middleboxes (ii), but actually GUT could also 
be used to go around/through firewalls, you just run GUT through random 
ports, instead of the default port, and hope the firewall does not do 
DPI. ;)

But we deliberately don't want to seek firewall traversal which would be 
against the network admin's policies, but rather help in the lazy 
middlebox problem.

I'll reply to your other post about the technical issues you raise.

cheers,
Jukka

On 3.2.2010 14:13, Bob Briscoe wrote:
> Jukka,
>
> I'm about to send a review of your (& Nuutti's) GUT draft. But some of
> my review relates to Pasi's points in the old thread below. So I'll
> rekindle it, inline...
>
>>> I had discussed about a generic UDP tunneling scheme with a few IETF
>>> colleagues (including you) a couple of months ago, but the draft I
>>> started to write then got forgotten in my drawer.
>> don't recall what the end resul has been so far, probably against it.
>> My quick-and-dirty draft and spec just wanted to trigger some
>> discussion at least by making one proposal in that direction. The fact
>> still remains, a lot of protocols do not get through NATs or
>>> all protocols. The receiver of the UDP datagrams would need to carry
>>> out the de-multiplexing and forwarding to different protocol modules
>>> and manage the related state, which could as well be done
>>> "automatically" by the UDP implementatation, by using different port
>>> numbers for each protocol.
>
>> receiver, you just get the packet, remove the GUT header, reattach the
>> IP header, calculate a possible checksum if the encapsulated protocol
>> has one, and give the packet to the IP stack. The stack then handles the
>> protocols by itself as if it came from the interface directly, the GUT
>> implementation does not need to care about the local IP stack
>> implementation on Linux is only a few hundred lines of code, need to
>> check, but it was quite little (without the fragmentation and IP
>> option handling).
>>
>>> 2) (in my opinion) more elegantly, have a separate initiation phase:
>>> first, a client sends a message to a well-known UDP port and asks
>>> what is the UDP port number for tunneling protocol X. If the client
>>> gets a positive response, it can start sending UDP-tunneled protocol
>>> packets directly to the returned port Y without additional GUT header
>>> overhead. In such system it would be easy to add new protocols for
>>> experimentation, for example just by adding new entries in a
>>> configuration file processed by a small application that listens to
>>> the queries at a well-known UDP port and responds by returning the
>>> port numbers for tunneling the configured protocols.
>>
>> control message saying that subsequent packets should be sent to port
>> P from now on.
>
> I prefer something like the GUT approach to both of these. The choice is
> between:
> 1) wasting port numbers
> service. It needs to get started with minimum delay. The first datagram
> may be the only one, but fast start is still important even if it might
> be supporting connection-oriented services above it like DCCP or SCTP.
> Short flows are where all the value is on the Internet, so we don't need
> extra RTTs to get started. Then we might as well have used ATM.
>
> Building in an unnecessary extra RTT delay should only be contemplated
> if no other way will ever be possible.
>
> certain protocols, it gets no response - i.e. the blackhole is probably
> its own NAT).
>
>
>>> well-known port is allocated by IANA, it should be safe to assume it
>>> is used for this purpose. If there are malformed packets, for example
>>> from some older app that doesn't know GUT, they would likely be
>>> rejected at some point in the processing, because the content would
>>> not match any protocol state (or checksum calculation) of the inner
>>> protocol.
>>
>> This concept was taken from GIST where we use a magic number for this
>> exact purpose, verify that the packet truly (at some level of
>> confidence) is a GIST packet. You could live without it, sure, but you
>> can run into problems later due to unnecessary packet processing.
>
>>>> out-of-the-box D-link and Linksys NAT boxes in between). We need to
>>>> fix and add a few things, then we can release the implementation as
>>>> open source.
>>>>

-- 
Jukka MJ Manner, Professor, PhD.  Phone:  +358+(0)9+470 22481
Aalto University                  Mobile: +358+(0)50+5112973
Department of Communications      Fax:    +358+(0)9+470 22474
and Networking (Comnet)           Office: G320a (Otakaari 5A)
P.O. Box 13000, FIN-00076 Aalto   E-mail: [email-masked]
Finland                           www.netlab.hut.fi/~jmanner/

---

From: Pasi Sarolahti <[email-masked]>
Date: Wed, 3 Feb 2010 18:20:20 -0800

Hi Bob,

(cutting some of the past comments for Email economy)

On Feb 3, 2010, at 4:13 AM, Bob Briscoe wrote:

>>> I'm a little doubtful about the idea of using a single UDP port  
>>> for all protocols. The receiver of the UDP datagrams would need to  
> For me, the problem is that we are having to create a whole sub- 
> layer just to get back to where we were before badly designed NATs  
> were deployed. But if that's the best we can do, we need to grasp  
> the nettle.

I think this was more or less my concern, too. Why add another layer  
(and extra header overhead), if you could use different UDP port  
numbers to distinguish between protocols?

>>> phase: first, a client sends a message to a well-known UDP port  
>>> and asks what is the UDP port number for tunneling protocol X. If  
>>> the client gets a positive response, it can start sending UDP- 
>>> tunneled protocol packets directly to the returned port Y without  
>>> additional GUT header overhead. In such system it would be easy to  
>>> add new protocols for experimentation, for example just by adding  
>>> new entries in a configuration file processed by a small  
>>> application that listens to the queries at a well-known UDP port  
>>> and responds by returning the port numbers for tunneling the  
>>> configured protocols.
>>
> I prefer something like the GUT approach to both of these. The  
> choice is between:
> 1) wasting port numbers

Approach 2) would not necessarily need to waste an RTT. One could  
include the first packet from the inner protocol with the initiation  
message, if that just fits the MTU. Otherwise, I would agree that  
wasting an RTT is not desirable.

Approach 1) is what we do today. The advantage there is the minimal  
run-time overhead (whether in header bandwidth or RTTs), with the cost  
of administrative (IANA) overhead for each new protocol. There is some  
work in progress for SCTP and DCCP that falls into this category.

If wasting header bandwidth is the least of concerns, why not include  
a full IPv6 header in that case (i.e., do Teredo)?

- Pasi

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 04 Feb 2010 12:22:21 +0000

Pasi,

I think I might have just thought of a better idea - give me a while 
to check it through...

Bob

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 10 Feb 2010 12:32:42 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Bob Briscoe
> Sent: Wednesday, February 03, 2010 4:14 AM
> To: Jukka Manner; Pasi Sarolahti
> Cc: tsvwg
> Subject: Re: [tsvwg] Generic UDP tunneling (draft-manner-tsvwg-gut-00)
> 
> Jukka,
> 

This is entirely optional.  That is, if a host implements that
sub-layer, and its applications know about that sub-layer, then
they can all signal the same UDP port and demultiplex incoming
packets.  Outgoing packets to hosts that don't implement the
sub-layer would still be sent from that same UDP port, but
could be sent to a different UDP port on the peer.

Hosts that don't implement the sub-layer could use a different
UDP port for every GUT protocol.  As an extreme example, this
would even allow running DCCP at the application layer and running 
it over a GUT encapsulation.

> >>asks what is the UDP port number for tunneling protocol X.

RPC-like.

But that technique doesn't work well if both endpoints are behind 
their own NATs - the server is unlikely to get the necessary port 
number from its NAT (another server, also behind that NAT, will 
have already stolen that port number).

> >>If the 

A DNS query (which is cachable) could optimize the RPC-like 
port-learning mechanism.

> certain protocols, it gets no response - i.e. the blackhole is 

FWIW, we described details for such a scheme in
http://tools.ietf.org/html/draft-wing-http-new-tech-00#section-4.2

-d

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 10 Feb 2010 22:11:09 +0000

Dan,

> > deployed. But if that's the best we can do, we need to grasp

[BB]: Dan, Can you write the next couple of paras again, but make it 
clearer when you are talking about a src port or a dst port? I found 
it really tough to unravel what you meant. Here's some guesses for 
the words in which the ambiguity/confusion might lie:
- sub-layer (the GUT encapsulation sub-layer?)
- signal (session/app layer advertisement of the port vs. 'send to'?)
- same (same as in the previous case vs. well-known?)

>could be sent to a different UDP port on the peer.

[BB]: But if the receiver doesn't implement the sub-layer, surely it 
won't know what to do with GUT encapsulated datagrams?

>it over a GUT encapsulation.

[BB]: Again, if they don't implement the sub-layer, surely they won't 
know what to do with GUT encapsulated datagrams?

>have already stolen that port number).

[BB]: Good point.

>A DNS query (which is cachable) could optimize the RPC-like

[BB]: That's a faff for granny to register her ports in her ISP's 
DNS. The thing I liked about GUT was it just works without depending 
on other stuff.

>http://tools.ietf.org/html/draft-wing-http-new-tech-00#section-4.2

[BB]: Cool.

Thinking about draft-tuexen-sctp-udp-encaps, do you agree, tho, that 
a general-purpose UDP tunnelling daemon would be much better than one 
for SCTP and one for every sexyNewTP.

Note that GUT could also be used to bypass home gateways that block 
new TCP options (e.g. ECN, window-scaling).

Here's a good justification for why doubling up on initial packets 
isn't harmful:
Wischik, D., "Short Messages," In: Proc. Workshop on Networks: 
Modelling and Control, Royal Society (September 
2007)  http://www.cs.ucl.ac.uk/staff/ucacdjw/Research/shortmsg.html

PS. Dan, you might be able to answer a question Jukka asked (offlist) 
about IP fragmentation. If a source sends IP fragments to a NAT-PT, I 
assume the NAT-PT reassembles them before port translating, then 
re-fragments them if they are still too big for the rest of the path. 
Am I correct?

You can see why this might be a concern, given GUT encapsulation 
increases the size of each packet slightly.

Cheers

Bob

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 10 Feb 2010 15:44:45 -0800

> From: Bob Briscoe [mailto:[email-masked]] 
> Sent: Wednesday, February 10, 2010 2:11 PM
> To: Dan Wing
> Cc: 'Jukka Manner'; 'Pasi Sarolahti'; 'tsvwg'
> Subject: RE: [tsvwg] Generic UDP tunneling (draft-manner-tsvwg-gut-00)
> 
> Dan,
> 

Here is my attempt to re-state, in something approaching I-D
language:

  (in the Receiver Operation section)

  There are two ways to implement a receiver:  listening on one
  UDP port for all GUT-encapsulated traffic, or listening on 
  different UDP ports per protocol.

  A receiver MAY support both, at the same time.  It is also
  possible that some GUT-encapsulated traffic is handled by
  the underlying IP stack and traffic arrives on one UDP port
  (e.g., a transport protocol implemented by the host's IP
  stack such as SCTP-over-GUT), while, at the same time, other 
  GUT-encapsulated traffic is handled entirely at the application 
  level on a different UDP port (e.g., a new transport protocol 
  not implemented by the host's IP stack).

  ONE UDP PORT FOR ALL GUT-ENCAPSULATED PROTOCOLS:

  A receiver may be implemented to receive multiple GUT-encapsulated 
  protocols on the same UDP port.  This reduces the number of UDP ports
consumed
  by the receiver which has some value (e.g., reducing port consumption 
  when behind a NAT).  When the receiver does so, the receiver is
  responsible for demultiplexing incoming GUT-encapsulated packets
  and dispatching them to the appropriate protocol handler.

  ONE UDP PORT FOR EACH GUT-ENCAPSULATED PROTOCOL:

  A receiver may be implemented to receive each GUT-encapsulated protocol
  on a different UDP port.  This consumes more UDP ports, but removes
  the need to demultiplex incoming packets.  This also allows an
  application to wholly implement a transport-level protocol inside
  the application, if necessary (e.g., due to lack of support or 
  features in the underlying IP stack).

> DNS. The thing I liked about GUT was it just works without depending 

I said 'optimize'; I did not say 'rely solely and exclusively on DNS'.

I'm trying to throw out other ideas to reduce the RTT objection.  I
liked the other idea in the thread to send the first GUT-encapsulated
data packet in that RPC-like message (e.g., the SCTP INIT goes in 
that RPC-like message).

> for SCTP and one for every sexyNewTP.

Yes.

I didn't state that, but I meant to:  I support a general UDP-based
encapsulation over one-application-for-every-protocol.

> new TCP options (e.g. ECN, window-scaling).

Yep.

> re-fragments them if they are still too big for the rest of the path. 

Stateless NAT64 translation (draft-ietf-behave-v6v4-xlate, which is 
effectively RFC2765bis) does not do anything at all with ports, and
will simply pass fragmented packets along (truncating IPv6's
32-bit Identification field to IPv4's 16-bit Identification field).

Stateful NAT64 translation (draft-ietf-behave-v6v4-xlate-stateful-08),
which aggregates multiple IPv6 hosts onto one IPv4 address and thus
does change TCP and UDP port numbers, says:

      The NAT64 MUST handle fragments.  In particular, NAT64 MUST handle
      fragments arriving out-of-order , conditioned on the following:

      *  The NAT64 MUST limit the amount of resources devoted to the
         storage of fragmented packets in order to protect from DoS
         attacks.

      *  As long as the NAT64 has available resources, the NAT64 MUST
         allow the fragments to arrive over a time interval.  The time
         interval SHOULD be configurable and the default value MUST be
         of at least FRAGMENT_MIN.

      *  The NAT64 MAY require that the UDP, TCP, or ICMP header be
         completely contained within the fragment that contains OFFSET
         equal to zero.

To my knowledge, there have not been significant testing of how
well commonly-available NATs handle UDP fragments.  There used to
be significant problems with out-of-order fragments (they were
simply dropped), and that was triggered by now-historic Linux
UDP stacks which would send packets out of order on purpose.

> increases the size of each packet slightly.

To avoid PMTUD blackholes, it is probably worth considering having
GUT adjust the upper layer's equivalent of TCP's MSS according to 
the additional GUT overhead, much as most tunnels do today.  

Another idea, but perhaps out of scope for GUT and more appropriate
for generalized use by any sort of tunnel, not just GUT:  Have GUT 
be more intelligent and determine if there is a PMTUD blackhole 
on the path.  If PMTUD works on that path, GUT could leave the 
(encapsulated protocol's equivalent of) TCP MSS alone (thus allowing 
a larger MTU for the transport); if PMTUD blackholes, GUT could 
reduce the (encapsulated protocol's equivalent of) TCP MSS, so
the transport doesn't have to suffer the delays of blackhole 
discovery.

It would complicate GUT somewhat, but I wonder if it would be 
valuable for GUT, itself, to contain sequence numbers and do
its own reassembly rather than relying on IP fragmentation.

If I hit a gnat with a flyswatter, I'm left with gnat guts on 
the wall.

-d

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 11 Feb 2010 01:01:42 +0000

Dan,

>Here is my attempt to re-state, in something approaching I-D

OK, the misunderstanding was: where you had said a "host implements" 
I hadn't picked up the intended meaning of "in kernel land".

>   features in the underlying IP stack).

Yup. These are two of Pasi's original options.

I still don't see there's any more than a nat's (sic;) crotchet of 
difference in processing between:
1) a single receiving GUT daemon reads 'next header' = N from the GUT 
fields, puts N in the IP header, removes GUT and dispatches to 
protocol handler N.
2) each dedicated receiving GUT daemon running on a specific port has 
'next header' = N hard-coded, it puts N in the IP header, removes GUT 
and dispatches to protocol handler N.

The problem with 2) is that it doesn't help deployment of nextSexyTP 
we haven't yet invented. Whereas, once a single GUT daemon gets 
shipped on every machine out of the box, we're done forever (until 
the next big son-of-NAT kludge screws this all up too).

>data packet in that RPC-like message (e.g., the SCTP INIT goes in

I still don't see the advantage of port-learning vs just using a 
well-known port. It's just added complexity for no important gain.

>          completely contained within the fragment that contains OFFSET

Thanks for this knowledge.

>UDP stacks which would send packets out of order on purpose.

Yes, this is the sort of knowledge Jukka & I are primarily interested 
in - *proprietary* NAT-PTs (I believe you have a collection). I'm not 
so worried about NATs that follow standards. The whole point of GUT 
is to get round bad crap; good crap's not such a problem.

>the transport doesn't have to suffer the delays of blackhole

All good stuff. Thanks & agreed.

>its own reassembly rather than relying on IP fragmentation.

That's what Jukka has been thinking. I wouldn't go there - Do one 
thing and do it well. If we want to fix crap IP reassembly on 
middleboxes, we should do that separately (IMHO).

>If I hit a gnat with a flyswatter, I'm left with gnat guts on

I do gnat-gutting in my spare time too.

Cheers

Bob

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 15 Feb 2010 10:13:02 -0800

Bob Briscoe [mailto:[email-masked]]  wrote:

> we haven't yet invented.

But it does allow nextSexyTP to be implemented in user-space without
needing GUT support in the OS's IP stack.  For example, BitTorrent's 
uTP could use GUT if GUT can be implemented in user-space (let's not get 
into a discussion of the merits of uTP; that isn't why I cited it).

Another possible advantage with (2) is we could have a "GUT-less
GUT" -- either without a GUT header or with a shorter GUT header.
This could save some GUT overhead for whatever that's worth (perhaps
not much, considering we're already suffering by adding a UDP
header).

> Whereas, once a single GUT daemon gets 

Using a well-known port, exclusively, means we can't have two
GUT listeners (server) behind the same NAPT device.  Which means 
GUT would be restricted to pure client/server and the server 
would need a publicly-routable IP address.

If we have some port agility, we can avoid that limitation and
can have many GUT listeners (servers) behind a single NAPT.

> >Stateful NAT64 translation 
> (draft-ietf-behave-v6v4-xlate-stateful-08),

Gotcha.  Makes sense.

> middleboxes, we should do that separately (IMHO).

Sounds reasonable.

Doing reassembly at the UDP layer would, IMO, be pretty valuable
considering how hosed PMTUD is on the Internet.

-d

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 16 Feb 2010 18:43:37 +0000

Dan,

>into a discussion of the merits of uTP; that isn't why I cited it).

While I'm convinced by your 'servers behind NATs' argument below for 
approach #2 (port agility), I'm not convinced by this one. 
Conceptually the GUT daemon puts an IP header back on the datagram 
after removing UDP+GUT. So, to get to user-land, the next header 
after GUT ought to be something in kernel space, such as UDP, which 
in turn will encapsulate the uTP protocol. So, why not just start 
with uTP over UDP, or nextSexyTP over UDP?

IOW, getting to user-land via UDP is not a problem. The problem GUT 
addresses is getting new 'next header' fields in the IP header across 
NATs. Or new variants of protocols that NATs support (UDP, TCP etc) 
but only in their unmodified form.

>not much, considering we're already suffering by adding a UDP

Here's a GUTless protocol idea I suggested offlist to Jukka, that can 
work with approach #1 (well-known port) or #2 (port agility). If 
GUTless datagrams are sent to a well-known port or a port that knows 
it will receive GUTless datagrams, the receiving host could interpret 
any datagram arriving at this port as complying with the GUTless 
protocol header below. It looks more similar to UDP, but borrows 
concepts from UDPTT (Gorry's UDP transport tunnelling), UDP-lite and 
GUT. Ie, if the UDP dst port is GUT_P or a known alternative, the UDP 
header is effectively redefined to be a GUTless header as follows:

                     0              15 16             31
                    +--------+--------+--------+--------+
                    |     Source      |   Destination   |
                    |      Port       |Port = GUTless_P |
                    +--------+--------+--------+--------+
                    |  Next  |Checksum|     Checksum    |
                    | Header |Coverage|                 |
                    +--------+--------+--------+--------+
                    |                                   |
                    :          GUTless Payload          :
                    |  integrity checked up to coverage |
                    +-----------------------------------+

I.e. the length field of the UDP header (also called the checksum 
coverage field in UDP-lite) isn't necessary if you know it's only 
used for tunnelling, because you can get the datagram size from the 
IP module and you know (expect) there's another transport length 
field later for checksumming the inner transport header and its 
payload. So this field becomes available for other uses.

It can hold the next header ID and still have 8bits for specifying 
checksum coverage. No need for any header fields beyond 8 octets (but 
you could add a chain of next headers before the transport header if 
you wanted).

The 8-bit checksum coverage allows you to have 2^8 = 256 octets of 
extension headers before the inner transport protocol which is 
assumed to have its own checksumming facilities. If this isn't 
enough, we could define this field as counting in 4-octet units, 
rather than single octets. But that may be a conceptual shift too far from UDP.

Downsides:
- no spare bits.
- it was designed assuming a well-known GUTless port - it's not 
self-evident whether the header is UDP or GUTless if you have port agility.

>can have many GUT listeners (servers) behind a single NAPT.

This is a very good point - hadn't thought of this.

I guess the best of both worlds would be a well-known GUT port and 
the ability to have port agility too. Then you don't have to do port 
# discovery, but if the sndr & rcvr know a special port # through 
some pre-shared context, there's nothing to stop them using it 
(similarly, anyone can use apps bound to existing well-known ports on 
other ports).

>considering how hosed PMTUD is on the Internet.

Can you explain how you're thinking of solving PMTUD problems at a 
higher layer?

Bob

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 16 Feb 2010 10:56:56 -0800

> Sent: Tuesday, February 16, 2010 10:44 AM
> To: Dan Wing

That's fair.  I agree that this isn't a strong justification.

> header is effectively redefined to be a GUTless header as follows:

When signaling the port number, the need for a GUT header could
also be signaled.

> (similarly, anyone can use apps bound to existing well-known ports on 

Yes, that would work fine.

> Can you explain how you're thinking of solving PMTUD problems at a 

Something like draft-petithuguenin-behave-stun-pmtud, which uses
packetization layer PMTUD (RFC4821).

GUT could send/receive the similar packets itself to learn the
path MTU, and then either (a) communicate that MTU to the application 
using the GUT API or (b) have GUT use the path MTU information 
itself to UDP packets that are smaller than the MTU.

Having GUT provide useful features to application developers, so
they don't need to worry about path MTU, can help GUT deployment
and GUT's success over the Internet.  At least, that's why I
think it's a good idea.  :-)

-d