Subject: [grobj] Problem statement

From: Simon Perreault <[email-masked]>
Date: Wed, 11 Nov 2009 19:28:15 +0900

Hello,

So today at the BoF meeting people felt that the problem was not clearly
defined.

This was also my feeling. Right now, the problem that application
developers have is simple: they want to do something ICE-like but they
end up mostly recreating the wheel every time. A clear and easy to
understand problem. And clearly solvable too: rip ICE out of the SIP
world and create a stand-alone, versatile protocol for communicating
candidates and performing connectivity checks.

In comparison, I'm not convinced that exchanging bunches of pointers to
a host in a standard format is a problem that application developers
have currently.

Simon
-- 
DNS64 open-source   --> http://ecdysis.viagenie.ca
STUN/TURN server    --> http://numb.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org

---

From: bo zhou <[email-masked]>
Date: Wed, 11 Nov 2009 18:35:55 +0800

As chair said, maybe we should define the problem more clearly if we really
want to make this as a work in IETF.
I can support this problem statement work voluntarily.

Regards,

Bo

On Wed, Nov 11, 2009 at 6:28 PM, Simon Perreault <
[email-masked]> wrote:

> _______________________________________________
> grobj mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grobj
>

-- 
Regards,

Bo Zhou
China Mobile

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Nov 2009 11:30:04 +1300

Yes, it's clear that a problem statement is the next step,
and it is very important to avoid "solutionism" in that
work. Both the existing draft, and Simon's note below,
show clear evidence of solutionism ;-)

I think getting a clear common understanding of the
problem between Layer 3 and Apps people is the most
important thing.

Regards
   Brian Carpenter

On 2009-11-11 23:35, bo zhou wrote:
> ------------------------------------------------------------------------
>

---

From: Scott Brim <[email-masked]>
Date: Thu, 12 Nov 2009 08:32:13 +0900

Simon Perreault allegedly wrote on 11/11/2009 7:28 PM:
> developers have is simple: they want to do something ICE-like 

I disagree that this is what app developers want.  If ICE was not
necessary for some apps, those app developers would be pleased not to
have to use it.  As Brian said, let's avoid point solutionism.  But it
is good to point out scenarios where there are problems with referrals,
and that is what should go into the draft in order to guide it.

Scott

---

From: bo zhou <[email-masked]>
Date: Thu, 19 Nov 2009 15:40:01 +0800

Agree with Scott.
So shall we draw potential scenarios for the referrals issue at first, then
identfy problem more clearly?

regards,

Bo

-- 
Regards,

Bo Zhou
China Mobile

---

From: Simon Perreault <[email-masked]>
Date: Thu, 19 Nov 2009 09:11:51 -0500

Scott Brim wrote, on 2009-11-11 18:32:
> But it

Let me try to feed this discussion...

Some problems that come to mind with draft-carpenter-behave-referral-object:

- The "scope" of an address (I'm still not fully understanding the concept) does
not guarantee that that the address is reachable from anyone in that scope. For
example, the address of a NAT binding (called a "reflexive transport address" in
RFC5389) can be reached by a subset of peers in the NAT's scope which depends on
the type of NAT (see e.g. RFC4787 for types of NATs).

- If someone hands me a net10 address, and I am also in net10, is it the same
net10 or a different one? How can I know? Should I even care?

- How are referrals used? It's clear in the draft that this is out of scope. But
I'm wondering if generic referrals are useful at all if this is left out of scope.

- How to prioritize items in a GRO? The draft says this is out of scope, but I
don't know how to use GRO without it.

Basically, for me it all boils down to "I don't understand what GRO is good for."

Some problems that come to mind with draft-bo-behave-ref-req:

- R1: "The referral formats need to be standardized." Are you sure about that?
I'm not convinced. Real-life examples would help.

- R2: "Simplify ALG during NAT traversal" Isn't the goal to remove the need for
ALGs completely instead of making creating them easier?

- To me the biggest drawback of this document is that it really doesn't try to
explain what the problem is. It jumps right into requirements for solutions. How
can we say we need a solution when we don't even agree on the problem?

Again, and now I'll try to refrain from using the term ICE to not be called a
"solutionist" ;-), one problem I see everyone having is doing NAT traversal
without reinventing the wheel.

Simon

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 19 Nov 2009 10:31:09 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Simon Perreault
> Sent: Thursday, November 19, 2009 6:12 AM
> To: Scott Brim
> Cc: [email-masked]
> Subject: Re: [grobj] Problem statement
> 
> not guarantee that that the address is reachable from anyone 
> in that scope.

Agreed.  But nothing can provide such a guarantee anyway.

The scope has a different purpose, which is to provide hints
that we *might* be on the same network.

For example, if my scope says "I'm on the cisco.com corporate
network", and your application knows (or has reason to believe) that
its host is not on that corporate network, the application need not
bother trying to access it.  The application knows this scope is
not a candidate path -- that is, this path is unlikely to work.
Mistakes happen; it could work, but it should not be tried first.

For example, if my scope says "I know this is on the Internet",
and your application knows it can also access the Internet, the
application knows this scope is a candidate path -- that is,
a path that might work.  Mistakes happen; it might not work, but
an evaluation of the scopes indicates it should work.

> For

You can't know for sure.  But various things can give you 
hints.  For example, the default domain name that is returned
via DHCP.  If they differ, you're more likely on different
networks.  This is never guaranteed to prove you're on 
different networks, but there aren't any guarantees.

> I'm wondering if generic referrals are useful at all if this 

Agreed.

> - How to prioritize items in a GRO? The draft says this is 
> out of scope, but I don't know how to use GRO without it.

That ties into 'how to do a referral'.

> Basically, for me it all boils down to "I don't understand 

It's the middle part of the 3 prongs that Dave Thaler described
at the end of meeting:

  - get/construct scope zone id
  - GRO, a way to communicate it
  - path selection

> "solutionist" ;-), one problem I see everyone having is doing 
> NAT traversal without reinventing the wheel.

That's the problem I see, too.  I think GRO is part of the solution
and we need to flesh out the solution (into three or possibly four 
parts), but you're right we need to flesh out the problem better.

To me, the problem is easy:  we want to provide guidance, and maybe
even a library, to applications so they can more easily handle
multi-homed hosts, IPv6/IPv4 translation, IPv4 NAT, tunnels, and a 
myrid of other cool things that make it complex for applications 
to work well with such complex networks.  We have lots of nifty
layer 3 and layer 4 things we have specified and vendors have 
built, but many applications are stymied trying to work with them
at all; yet, we want them to work well.

-d

---

From: Simon Perreault <[email-masked]>
Date: Thu, 19 Nov 2009 13:52:12 -0500

> an evaluation of the scopes indicates it should work.

So I understand that scope would be one criteria for determining priorities of
candidates. Makes sense.

But is it solving a problem we have? Does experience with ICE show that it would
be a nice feature to have?

I'm trying to understand the need for communicating scope IDs...

> to work well with such complex networks.

YES! +1

I want to do this:

  my $gro = $server->request('GETPEER');
  my $connection = $gro->connect();   # <-- MAGIC!
  print $connection "We are peer-to-peer networking!\n";

Simon

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 19 Nov 2009 11:04:59 -0800

> From: Simon Perreault [mailto:[email-masked]] 
> Sent: Thursday, November 19, 2009 10:52 AM
> To: Dan Wing
> Cc: 'Scott Brim'; [email-masked]
> But is it solving a problem we have? Does experience with ICE 
> show that it would be a nice feature to have?

It's useful to connect quickly so users are happy with the
experience.  If there are a lot of candidate addresses and 
candidate transports it's time-consuming to try all of them.

>   print $connection "We are peer-to-peer networking!\n";

Yep, that's the level I would really love to see.  And the
library can evolve separate from the application.  For example,
if/when the OSs can do draft-savolainen-mif-dns-server-selection
(if that achieves IETF consensus) the library would begin 
supporting it -- rather than applications having to diddle with
that level of (what I will call) "nonsense".

-d

---

From: Simon Perreault <[email-masked]>
Date: Thu, 19 Nov 2009 14:26:00 -0500

Dan Wing wrote, on 2009-11-19 14:04:
> If there are a lot of candidate addresses and 

Why not try all of them simultaneously? It would waste bandwidth, but probably
not a significant amount. If concerned you can impose a concurrency limit. Then
you use the equivalent of ICE's aggressive nomination but make it choose the
highest priority candidate (instead of the first successful one) that is
successful within a given time window following the first successful check.

Ok, now we're well into solutionist territory... ;)

> that level of (what I will call) "nonsense".

We're on the same wavelength here.

Simon

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 19 Nov 2009 11:37:09 -0800

> Sent: Thursday, November 19, 2009 11:26 AM
> To: Dan Wing
> Why not try all of them simultaneously? It would waste 
> bandwidth, but probably not a significant amount.

The transport area directors get into a tizzy.  

> If concerned you can impose a concurrency limit. Then

Yeah, and that's the sort of thing that removes the transport
area worry about flooding the network and harming existing
TCP-friendly flows.  

And that's what we would want applications to do.  But they
will do the naive thing (flood the network) and harm other
flows on their network -- including the IPTV between the
media player downstairs and the TV upstairs, including the
TCP streaming video coming down the Internet (TCP ACKs get
lost with aggressive probes), and so on.  All solved by
adding more bandwidth, but the industry keeps inventing 
new applications that use that additional bandwidth!

> Ok, now we're well into solutionist territory... ;)

:-)

> We're on the same wavelength here.

Cool.

Is Dave Thaler's suggestion for splitting the problem into three
things sufficient?

  1 get/construct scope zone id
  2 GRO, a way to communicate it
  3 path selection

If so, are there volunteers to start crafting outlines for (1) and (3)?

-d

---

From: Joel Halpern <[email-masked]>
Date: Thu, 19 Nov 2009 09:43:05 -0500

The whole point of the scope indication is to address you second bullet.  That is, with private addresses (or privately re-used public addresses), they can only be used in the specific scope (typically a company, although that is changing) over which they are defined.

If I am reading your first point correctly, there is a complication tucked in there which we can not solve, but need to acknowledge.  If a 
"global" scope address is allocated by a NAT, it may not be usable blobally.  The NAT description documents cover many behaviors, and only a few of them are arbitrarily usable addresses.  There are two paths for dealing with this.  The simpler, which is where I would start, is just to note that and move one.  The alternative requries far more coupling with STUN/TURN/ICE, and more active participation of all parties in the referral to make it work.

Yours,
Joel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Simon Perreault
Sent: Thursday, November 19, 2009 9:12 AM
To: Scott Brim
Cc: [email-masked]
Subject: Re: [grobj] Problem statement

Scott Brim wrote, on 2009-11-11 18:32:
> But it
> is good to point out scenarios where there are problems with 
> referrals, and that is what should go into the draft in order to guide it.

- The "scope" of an address (I'm still not fully understanding the concept) does not guarantee that that the address is reachable from anyone in that scope. For example, the address of a NAT binding (called a "reflexive transport address" in
RFC5389) can be reached by a subset of peers in the NAT's scope which depends on the type of NAT (see e.g. RFC4787 for types of NATs).

- If someone hands me a net10 address, and I am also in net10, is it the same net10 or a different one? How can I know? Should I even care?

- How are referrals used? It's clear in the draft that this is out of scope. But I'm wondering if generic referrals are useful at all if this is left out of scope.

- How to prioritize items in a GRO? The draft says this is out of scope, but I don't know how to use GRO without it.

- R2: "Simplify ALG during NAT traversal" Isn't the goal to remove the need for ALGs completely instead of making creating them easier?

- To me the biggest drawback of this document is that it really doesn't try to explain what the problem is. It jumps right into requirements for solutions. How can we say we need a solution when we don't even agree on the problem?

Again, and now I'll try to refrain from using the term ICE to not be called a "solutionist" ;-), one problem I see everyone having is doing NAT traversal without reinventing the wheel.

Simon

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 20 Nov 2009 09:15:42 +1300

(Trying to use separate subjects for separate topics;
at some point we may even need an issue tracker.)

The basic problem in my mind is that, since we destroyed address
transparency, you simply cannot tell by looking at an address
whether it is meaningfully reachable. This applies whether the address
is 10.1.1.1 or 9.1.1.1 (both of which are actually out of scope
where I am sitting at the moment, although RFC1918 only tells me
about one of them). Similarly for IPv6, you cannot tell by
looking at a globally unique address or a ULA whether or not
it's meaningfully reachable.

So, this in fact part of the problem statement: when a 3rd party
receives an IP address (communicated at application level),
it does not automatically know whether that address is meaningfully
reachable from its (the 3rd party's) location. We abbreviate that
by saying "the address is in/out of scope".

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 20 Nov 2009 09:21:33 +1300

> the type of NAT (see e.g. RFC4787 for types of NATs).

So, given what I just said about scope (with no reference to NATs), I think
Simon needs to tell us what he means by "in the NAT's scope".

To me an address scope is a set of mutually reachable addresses, which
means that a NAT automatically forms (part of) the boundary of a scope.
I don't understand what is meant by "a subset of peers" - surely all
the peers behind a given NAT (more precisely, behind a given interface
of a given NAT) are in the same address space?

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 20 Nov 2009 09:32:55 +1300

> successful within a given time window following the first successful check.

Actually this has been discussed quite a bit in the context of "what's wrong
with RFC3484?" It's also been implemented in the REAP protocol which is
associated with SHIM6. My student Habib Naderi is currently simulating
REAP's behaviour when exploring various numbers of address pairs. The work
isn't quite cooked enough yet to give numbers, but one of his conclusions
is that the actual amount of probe traffic caused by REAP is not a big
problem. However, the recovery time for a TCP session when an address pair
fails can be pretty long (tens of seconds to minutes), and I suspect that
using a probing method to make the initial choice of address pair would
also be slow.

So, circling back to the problem statement: the objective is to make the
best possible initial guess at the best address pair to use, and the
value of a GRO is to help the receiving entity make that best guess.

    Brian

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 19 Nov 2009 12:44:40 -0800

> On Behalf Of Brian E Carpenter
> Sent: Thursday, November 19, 2009 12:22 PM
> To: Simon Perreault
> Cc: [email-masked]
> Subject: [grobj] NATs and scope
> 

Maybe, if the topology is like:

       Internet
          |
          |
     "A Given NAT"
        /   \
   Host-A  Host-B

but not, if the topology is like:

       Internet
          |
          |
     "A Given NAT"
        /   \
   Host-A  "Another NAT"
              |    
           Host-B

-d

---

From: Simon Perreault <[email-masked]>
Date: Thu, 19 Nov 2009 16:00:22 -0500

> Simon needs to tell us what he means by "in the NAT's scope".

I meant the scope of the interface on the NAT that is usually labeled "WAN".
That's usually Internet-scope, but it's common to have multiple layers of NAT,
in which case the scope would be different.

> of a given NAT) are in the same address space?

Here's an example:

   LAN --------|NAT|---- WAN
10.0.0.0/8             Internet

A host in the LAN initiates a UDP "connection" to the WAN. The NAT allocates a
binding on its WAN interface, e.g. 192.0.2.1:1234. The scope of this is
"Internet" I would presume.

For some kinds of NAT devices, any host on the Internet can reach the host on
the LAN by sending packets to 192.0.2.1:1234.

For other kinds, only hosts to which the host in the LAN has previously talked
using this binding can reach it.

So even if hosts are in the same scope as 192.0.2.1:1234, they may not be able
to use it.

Simon

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 20 Nov 2009 10:51:25 +1300

> So even if hosts are in the same scope as 192.0.2.1:1234, they may not be able

OK. So, in my personal view of the universe, "in scope" means reachable
directly and without translation. We need to be precise about some
of these definitions, clearly.

   Brian

---

From: Keith Moore <[email-masked]>
Date: Thu, 19 Nov 2009 17:35:35 -0500

> value of a GRO is to help the receiving entity make that best guess.
"Picking the best" address is not the only viable strategy.  It makes
sense, for some applications, to concurrently utilize multiple paths. 
e.g. If your application is transferring large data sets, and it finds
that it has multiple paths between the endpoints available to it, it
makes sense to send data over each of those paths, and adjust the amount
of data sent over each according to the characteristics of each path, to
get the fastest transfer.   As a bonus you get the ability to survive
failures of individual paths.

Keith

---

From: Dong Zhang <[email-masked]>
Date: Fri, 20 Nov 2009 09:28:22 +0800

Hi,

>value of a GRO is to help the receiving entity make that best guess.
Imho, having a little information is better than nothing, although the 
objective is not enough to make the decision solely.

Thanks.
>    Brian

------------------				 
Dong Zhang
2009-11-20

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 20 Nov 2009 15:29:12 +1300

> failures of individual paths.

Absolutely. I don't see why a GRO can't be used to "prime" multipath
TCP.

    Brian