headers
S Woodside | 1 Jun 05:59
Picon
Favicon

Fwd: [Ans-research] IRTF ANS Meeting Announcement

I'm curious if a large adhoc network would have special multihoming 
requirements that multi6 might consider? Put together, scalable adhoc 
networks with the ability to multihome in a decentralized manner would 
be a very desirable technology for building flexible wireless networks 
for last-mile (urban) / last 15 miles (rural) access.

simon

Begin forwarded message:

> From: Elizabeth Belding-Royer <ebelding <at> cs.ucsb.edu>
> Date: Thu May 29, 2003  8:11:49  PM America/Montreal
> To: ans-research <at> www1.ietf.org, manet <at> ietf.org
> Cc: corson <at> flarion.com, ebelding <at> cs.ucsb.edu
> Subject: [Ans-research] IRTF ANS Meeting Announcement
>
> Hi,
>
> The first meeting of the new IRTF Ad hoc Network Scalability (ANS)
> research group will occur this Sunday at the Mobihoc conference
> hotel.  Included is the agenda for this meeting.  This is a somewhat
> fluid agenda as we are still finalizing the speakers.  However,
> the meeting will definitely start at 7pm Sunday evening.  We look
> forward to seeing many of you at the meeting.
>
> Scott and Elizabeth
>
> *****************************************************************
>
>
(Continue reading)

Permalink | Reply | 501 comments |
headers
Pekka Savola | 1 Jun 08:09
Picon

Re: Fwd: [Ans-research] IRTF ANS Meeting Announcement

On Sat, 31 May 2003, S Woodside wrote:
> I'm curious if a large adhoc network would have special multihoming 
> requirements that multi6 might consider? Put together, scalable adhoc 
> networks with the ability to multihome in a decentralized manner would 
> be a very desirable technology for building flexible wireless networks 
> for last-mile (urban) / last 15 miles (rural) access.

Perhaps it would be best to first try to figure out how single-homed 
internet connectivity would work :-).

But really, it's still a question on how you delegate the information 
about prefixes and choose your subnets.

For the multihomed case with multiple PA prefixes, I guess this would mean 
that every MANET node would have a fixed, unique-in-the-MANET site 
identifier (or multiple of them).  This could be used for delegating 
addresses and ensuring multiple nodes don't get weird ideas which parts of 
/48's they could use.

> Begin forwarded message:
> 
> > From: Elizabeth Belding-Royer <ebelding <at> cs.ucsb.edu>
> > Date: Thu May 29, 2003  8:11:49  PM America/Montreal
> > To: ans-research <at> www1.ietf.org, manet <at> ietf.org
> > Cc: corson <at> flarion.com, ebelding <at> cs.ucsb.edu
> > Subject: [Ans-research] IRTF ANS Meeting Announcement
> >
> > Hi,
> >
> > The first meeting of the new IRTF Ad hoc Network Scalability (ANS)
(Continue reading)

Permalink | Reply | 501 comments |
headers
S Woodside | 1 Jun 09:42
Picon
Favicon

Re: [Ans-research] IRTF ANS Meeting Announcement


On Sunday, June 1, 2003, at 02:09  AM, Pekka Savola wrote:
> On Sat, 31 May 2003, S Woodside wrote:
>> I'm curious if a large adhoc network would have special multihoming
>> requirements that multi6 might consider? Put together, scalable adhoc
>> networks with the ability to multihome in a decentralized manner would
>> be a very desirable technology for building flexible wireless networks
>> for last-mile (urban) / last 15 miles (rural) access.
>
> Perhaps it would be best to first try to figure out how single-homed
> internet connectivity would work :-).

This is done, fortunately, for a small mesh at least. Unfortunately, 
the system uses centralized management to configure which (single) 
gateway each node uses (the system is meshAP, the management is called 
wiana). I don't think management is necessary though. AODV should be 
capable of handling single-homing by having the gateway node route all 
of the external packets. The existing adhoc protocol would handle the 
rest.

> But really, it's still a question on how you delegate the information
> about prefixes and choose your subnets.
>
> For the multihomed case with multiple PA prefixes, I guess this would 
> mean
> that every MANET node would have a fixed, unique-in-the-MANET site
> identifier (or multiple of them).  This could be used for delegating
> addresses and ensuring multiple nodes don't get weird ideas which 
> parts of
> /48's they could use.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kurt Erik Lindqvist | 1 Jun 21:35
Picon

Fwd: Internet-Draft Cutoff Dates for Vienna, Austria (July 16-21, 2003)


Begin forwarded message:

> From: Internet-Drafts Administrator <internet-drafts <at> ietf.org>
> Date: fre maj 30, 2003  18:11:16 Europe/Stockholm
> To: IETF-Announce: ;
> Subject: Internet-Draft Cutoff Dates for Vienna, Austria (July 16-21, 
> 2003)
>
>
> NOTE: There are two (2) Internet-Draft Cutoff dates
>
> June 23rd: Cutoff for Initial Submissions (new documents)
>
> All initial submissions(-00) must be submitted by Monday, June 23rd,
> at 09:00 ET.  Initial submissions received after this time will NOT be
> made available in the Internet-Drafts directory, and will have to be
> resubmitted.
>
>
> As before, all initial submissions (-00.txt) with a filename beginning
> with a draft-ietf MUST be approved by the appropriate WG Chair prior to
> processing and announcing. WG Chair approval must be received by
> Monday, June 16th.
>
>  Please do NOT wait until the last minute to submit.
>
> Be advised: NO placeholders. Updates to initial submissions received
>             the week of June 23rd will NOT be accepted.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kurt Erik Lindqvist | 1 Jun 21:34
Picon

Fwd: To the attention of all WG Chairs


If you haven't seen this.

If you are planning to send something in with a short dead-line and you 
think it is really important to multi6, please contact me.

- kurtis -

Begin forwarded message:

> From: Internet-Drafts Administrator <internet-drafts <at> ietf.org>
> Date: fre maj 30, 2003  18:11:24 Europe/Stockholm
> To: IETF-Announce: ;
> Subject: To the attention of all WG Chairs
>
>
>   In order to process the many version 00 I-Ds that are received
> before an IETF meeting in a timely manner, we ask that you send a LIST 
> OF
> THE NAMES of the drafts you expect to have submitted and have approved 
> for
> publication as WG documents to internet-drafts <at> ietf.org  no later than 
> five
> (5) business days prior to the cutoff date for the meeting.
>
>    Please include the word "Permission" in the Subject field.
>
>    This procedure will expedite the posting of version 00 I-Ds, 
> allowing
> more time for review by the public.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Randy Bush | 11 Jun 21:53

RE: draft-ietf-multi6-multihoming-requirements-06.txt

An Ops-Dir reviewer had the appended comments.  excuse the droll
phrasing.  any chance we could address them?

randy

---

Let's see: load balancing is not a realistic requirement.  For the
architecture to be automatic, we have to be dynamic and we've
proven that we don't know how to do that yet.  Even to give people
some tools seems to lead to abuse.  Who controls the balancing? 
The source?  The destination?  Don't say 'both'.  No packet can
serve two masters.

Performance.  Exact same arguments since the only way to affect
performance is to load balance.

Policy: so ill stated as to be meaningless.  If this is a call
for policy routing, that's fine, but it has nothing to do with
multihoming.

Simplicity: motherhood, apple pie and chevrolet.

Transport survivability: Well, ok, but this is just a refinement
of the redundancy requirement.  How about we remove the redundant
redundancy
requirement?

Compatible with DNS: meaningless
(Continue reading)

Permalink | Reply | 12 comments |
headers
Iljitsch van Beijnum | 12 Jun 00:55
Favicon

Re: draft-ietf-multi6-multihoming-requirements-06.txt

On woensdag, jun 11, 2003, at 21:53 Europe/Amsterdam, Randy Bush wrote:

> Let's see: load balancing is not a realistic requirement.  For the
> architecture to be automatic, we have to be dynamic and we've
> proven that we don't know how to do that yet.  Even to give people
> some tools seems to lead to abuse.  Who controls the balancing?
> The source?  The destination?  Don't say 'both'.  No packet can
> serve two masters.

No load balancing whatsoever means having a primary connection and a 
backup. For most multihomers paying for bandwidth you only get to use 
less than 1% of the time is a non-starter.

> Performance.  Exact same arguments since the only way to affect
> performance is to load balance.

Having a fast link, adding a slow one and having performance limited by 
the slow one is again unaccaptable.

And it's not like providing some basic load balancing is a huge deal. A 
simple preference value for each of multiple AAAA records or some such 
would go a long way.

> The real requirements are:

> 	- Provide multihoming
> 	- Provide scalable routing
> 	- Transport survivability

The real real requirement is: it must be good enough that people will
(Continue reading)

Permalink | Reply | 2 comments |
headers
Pekka Savola | 12 Jun 08:10
Picon

Re: draft-ietf-multi6-multihoming-requirements-06.txt

On Thu, 12 Jun 2003, Iljitsch van Beijnum wrote:
> On woensdag, jun 11, 2003, at 21:53 Europe/Amsterdam, Randy Bush wrote:
> 
> > Let's see: load balancing is not a realistic requirement.  For the
> > architecture to be automatic, we have to be dynamic and we've
> > proven that we don't know how to do that yet.  Even to give people
> > some tools seems to lead to abuse.  Who controls the balancing?
> > The source?  The destination?  Don't say 'both'.  No packet can
> > serve two masters.
> 
> No load balancing whatsoever means having a primary connection and a 
> backup. For most multihomers paying for bandwidth you only get to use 
> less than 1% of the time is a non-starter.

The real question was about *controlled, fine-grained* load balancing.  
That's entirely different than e.g. advertising identical prefix to two
ISP's in an identical fashion.

--

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Permalink | Reply | 1 comment |
headers
Iljitsch van Beijnum | 12 Jun 09:22
Favicon

Re: draft-ietf-multi6-multihoming-requirements-06.txt

On donderdag, jun 12, 2003, at 08:10 Europe/Amsterdam, Pekka Savola 
wrote:

>> No load balancing whatsoever means having a primary connection and a
>> backup. For most multihomers paying for bandwidth you only get to use
>> less than 1% of the time is a non-starter.

> The real question was about *controlled, fine-grained* load balancing.
> That's entirely different than e.g. advertising identical prefix to two
> ISP's in an identical fashion.

Our anonymous friend seems opposed to any kind of load balancing: "Even 
to give
people some tools seems to lead to abuse."

The "abuse" we see today is mostly due to people wanting to prevent 
certain traffic from taking a certain route as long as there is full 
connectivity rather than trying to balance traffic over two or more 
connections. For the former you quickly arrive at announcing more 
specifics, for the latter this is seldom necessary.

And also: "Who controls the balancing? The source?  The destination?  
Don't say 'both'." This shows the author brings some assumptions to the 
table that don't hold up for load balancing in multihomed networks. 
Sure, if A and B are directly connected over two circuits and A prefers 
to use 1 while B wants to use 2, you have a problem. But with 
multihoming A's choice of the outgoing circuit doesn't automatically 
dictate B's incoming circuit. And even if it did, shifting the traffic 
where the other end doesn't care should be sufficient in most cases.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joe Abley | 12 Jun 11:58
Favicon

Re: draft-ietf-multi6-multihoming-requirements-06.txt

On Wednesday, Jun 11, 2003, at 22:53 Africa/Kampala, Randy Bush quoted:

> Let's see: load balancing is not a realistic requirement.  For the
> architecture to be automatic, we have to be dynamic and we've
> proven that we don't know how to do that yet.

For load balancing to be possible, the architecture does not need to be 
fully automatic. Load balancing is perfectly possible today using 
automatic mechanisms which are tuned manually.

> Even to give people
> some tools seems to lead to abuse.

Some clarification on this sentence would be useful; I am struggling to 
understand it.

>   Who controls the balancing?
> The source?  The destination?  Don't say 'both'.  No packet can
> serve two masters.

If I am multi-homed, then I control the relative egress loading on my 
various transit circuits by managing my exit selection policies to 
choose exits which tend to balance traffic in a way that makes me happy.

I control the relative ingress loading by supplying clues to my transit 
providers and thereby attempting to influence the exit selection 
policies of those transit providers, and so on for all inbound traffic 
through the chain of ASes which leads to its source.

Both ingress and egress loading policies are necessarily malleable,
(Continue reading)

Permalink | Reply | 0 comments |

Gmane