Dan,

At 18:13 15/02/2010, Dan Wing wrote:
>Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk] wrote:
>
> > Dan,
> >
> > 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).

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.


>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).

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.

> > 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.

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).

> > >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.

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



Bob



>-d
>

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design