Subject: Re: [geonet/its] app-layer or network-layer problem (was: Internet-wide Geonetworking problem statement and challenges/open issues)

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 06 Dec 2013 16:20:45 +0100

Le 15/11/2013 20:51, Rex Buddenberg a écrit :
[...]
> Are you positing an application layer problem (7) or a network layer
> problem (3)?  It makes a whole lot of difference.

I think we definitely need to posit this as a network layer problem, and 
not an application layer problem.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 06 Dec 2013 16:23:10 +0100

Le 16/11/2013 19:43, Melinda Shore a écrit :
[...]
> The rest take the form of requirements, and it's almost certainly
> early for that.  A crisp problem statement will help identify
> requirements and I don't think you're there yet.  I'd
>
> . drop the reference to communication modes

I am not sure which communication modes?  Is it from the geonet problem 
statement I-D?

> . change the security text to something along the lines of
>    "Given the sensitivity of location data and the possibility
>    of the technology being used in emergency and/or road
>    traffic management scenarios we will pay particular
>    attention to security and privacy.  A thorough threat
>    analysis will be conducted, and mitigations specified in
>    any protocol documents which are developed.  Also:
>    geopriv

I agree.

> . frame any discussion of reliability in terms of the needed
>    transport characteristics.  I don't know what "reliable"
>    means here and you'll need to be clearer about that in any
>    event.  For example, does reliable mean guaranteed delivery
>    or does it mean timely delivery?  Etc.

I agree.

Alex

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

---

From: Nabil Benamar <[email-masked]>
Date: Fri, 6 Dec 2013 15:54:54 +0000

Hi all

Difenetly, it's a network layer issue since the draft focuses on the
encapsulation issues of Ipv6 in IEEE802.11p
Best
On Dec 6, 2013 3:20 PM, "Alexandru Petrescu" <[email-masked]>

---

From: Rex Buddenberg <[email-masked]>
Date: Fri, 06 Dec 2013 09:22:51 -0800

In which case you'll find that Lat/Lon routing table inputs are not a
good idea.

There are many metrics that have driven routing table preferences over
the years.  The first was simply hop count (see RIP) which didn't
account for heterogeneity in capacity nor congestion.  Nor ownership of
the plumbing.  The routing information protocols have become more
sophisticated over the years.

Because of the enormous (e.g. 10,000x) differences between link
capacities in this environment there will be many cases where a
multiple-hop route over high capacity (i.e. wired) links will be better
than, say, a three-hop route over all-radio.  

On Fri, 2013-12-06 at 15:54 +0000, Nabil Benamar wrote:
> On Dec 6, 2013 3:20 PM, "Alexandru Petrescu"
> <[email-masked]> wrote:
>         I think we definitely need to posit this as a network layer
>         problem, and not an application layer problem.
>         
>         Alex
>         
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 07 Dec 2013 17:35:09 +0100

Hi Rex,

On 06/12/2013 18:22, Rex Buddenberg wrote:
> In which case you'll find that Lat/Lon routing table inputs are not
> a good idea.

I think I agree.

Lat/Lon routing table entries would be very different than IP
address-based entries.  For one, these geo coordinates have a notion of
precision value attached to them, whereas IP addresses are 100% precise
(we never say _approximately_ 192.168.1.1).

I think the geo- coordinates-based routing and searching may be too far
fetched compared to what we'd like to achieve here.

That said, we still need to better identify what we need to deal with
here.  That must be network-layer, in relationship with geography, and
with the Internet (geonet).

Alex

>
> There are many metrics that have driven routing table preferences
> over the years.  The first was simply hop count (see RIP) which
> didn't account for heterogeneity in capacity nor congestion.  Nor
> ownership of the plumbing.  The routing information protocols have
> become more sophisticated over the years.
>
> multiple-hop route over high capacity (i.e. wired) links will be
> better than, say, a three-hop route over all-radio.
>
>
>
>> Difenetly, it's a network layer issue since the draft focuses on
>> the encapsulation issues of Ipv6 in IEEE802.11p Best
>>
>> <[email-masked]> wrote: Le 15/11/2013 20:51, Rex
>> Buddenberg a écrit : [...] Are you positing an application layer
>> problem (7) or a network layer problem (3)?  It makes a whole lot
>> of difference.
>>
>> _______________________________________________ its mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/its
>
>
>

---
Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active.
http://www.avast.com