Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk]  wrote:

> Dan,
> 
> At 23:44 10/02/2010, Dan Wing wrote:
> 
> >
> >
> > > -----Original Message-----
> > > From: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk]
> > > 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,
> > >
> > > At 20:32 10/02/2010, Dan Wing wrote:
> > > > > -----Original Message-----
> > > > > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org]
> > > > > 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,
> > > > >
> > > > > 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:
> > > > > 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.
> > >
> > > [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?)
> >
> >Here is my attempt to re-state, in something approaching I-D
> >language:
> 
> OK, the misunderstanding was: where you had said a "host implements" 
> I hadn't picked up the intended meaning of "in kernel land".
> 
> 
> >   (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).
> 
> 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.

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 
> 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).
> 
> > > >A DNS query (which is cachable) could optimize the RPC-like
> > > >port-learning mechanism.
> > >
> > > [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.
> >
> >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).
> 
> 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.

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.

> > > 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?
> >
> >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.
> 
> Thanks for this knowledge.
> 
> >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.
> 
> 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.

Gotcha.  Makes sense.

> > > You can see why this might be a concern, given GUT encapsulation
> > > 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.
> 
> All good stuff. Thanks & agreed.
> 
> 
> 
> >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.
> 
> 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).

Sounds reasonable.

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

-d

> >If I hit a gnat with a flyswatter, I'm left with gnat guts on
> >the wall.
> 
> I do gnat-gutting in my spare time too.
> 
> Cheers
> 
> 
> 
> Bob
> 
> 
> >-d
> >
> >
> > > Cheers
> > >
> > >
> > > Bob
> > >
> > >
> > >
> > >
> > > >-d
> > > >
> > > > > >>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
> > > > >
> > >
> > > ________________________________________________________________
> > > Bob Briscoe,                                BT Innovate & Design
> > >
> 
> ________________________________________________________________
> Bob Briscoe,                                BT Innovate & Design 
>