In message
Mark Townsley writes:
> When a host connects to a different link covered by a different subnet,
> indeed it will require a new IP address. That's pretty fundamental to what
> a subnet is. Hosts are getting better and better at handling multiple
> addresses, of both versions, coming an
When a host connects to a different link covered by a different subnet,
indeed it will require a new IP address. That's pretty fundamental to what
a subnet is. Hosts are getting better and better at handling multiple
addresses, of both versions, coming and going. MPTCP should continue to
help in th
On Mon, 23 Feb 2015, Ole Troan wrote:
are you replying to the point I made? cause fully functioning MHMP
requires host support (read MP-TCP/session layer) regardless of moving
or not.
If I extrapolated correctly what Juliusz wrote, that is not what he had in
mind.
with regards to a proposa
>>> On 21 Feb 2015, at 16:06 , Juliusz Chroboczek
>>> wrote:
>>>
> The client is running a stub implementation of the routing protocol.
>>>
I thought we already had decided we didn't require changes to the host?
>>>
>>> We don't *require* changes to the host. We propose optional host
On Mon, 23 Feb 2015, Ole Troan wrote:
On 21 Feb 2015, at 16:06 , Juliusz Chroboczek
wrote:
The client is running a stub implementation of the routing protocol.
I thought we already had decided we didn't require changes to the host?
We don't *require* changes to the host. We propose o
> On 21 Feb 2015, at 16:06 , Juliusz Chroboczek
> wrote:
>
>>> The client is running a stub implementation of the routing protocol.
>
>> I thought we already had decided we didn't require changes to the host?
>
> We don't *require* changes to the host. We propose optional host
> modification
On Sat, Feb 21, 2015 at 09:29:17PM +0100, Juliusz Chroboczek wrote:
> >> (Recall that multicast is 2Mbit/s at the phy. 13ms for a full-size frame,
> >> not counting the cost of collisions.)
>
> > Ok. But we also need a way to support fast router redundancy IMHO.
>
> Could you please explain what
>> (Recall that multicast is 2Mbit/s at the phy. 13ms for a full-size frame,
>> not counting the cost of collisions.)
> Ok. But we also need a way to support fast router redundancy IMHO.
Could you please explain what you mean?
-- Juliusz
___
homenet
On Sat, Feb 21, 2015 at 08:48:29PM +0100, Juliusz Chroboczek wrote:
> (Recall that multicast is 2Mbit/s at the phy. 13ms for a full-size frame,
> not counting the cost of collisions.)
Ok. But we also need a way to support fast router redundancy IMHO.
Cheers
Toerless
> > Something as simple
> I am not sure how important it is to separate fast-hello from route
> announcements for hosts. We may have <= 10 addresses on a host. Where would
> be have a problem ?
Radio congestion due to the announcements from the routers, which in RIP
would be advertising the whole network every Update int
Of course you're right, but let me play devils advocate for a bit:
I am not sure how important it is to separate fast-hello from route
announcements for hosts. We may have <= 10 addresses on a host. Where would
be have a problem ? processing in the receiving router ?
Something as simple as RIP
> I think i had tuned down the RIP hello interval.
Impossible. It was the Update interval that you had tuned down.
> I probably would prefer not to use one of the real routing protocols, but
> something lightweight. RIP is a stupid routing protocol but just to
> announce aliveness of host interf
I ran RIP on ca. 50 multi-homed clients in the early 90'th wth /32 route
injection
for both addresses, which effectively was also used for what we'd call
mobility today. Worked very good. Trying to remember the
reconvergence time after link down... I think i had tuned down the
RIP hello interval.
>> The client is running a stub implementation of the routing protocol.
> I thought we already had decided we didn't require changes to the host?
We don't *require* changes to the host. We propose optional host
modifications that improve the user experience.
The chairs will correct me if I'm wr
On Sat, 21 Feb 2015, Juliusz Chroboczek wrote:
The client is running a stub implementation of the routing protocol.
I thought we already had decided we didn't require changes to the host?
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
homenet
L3 - route injection (got a routing protocol there already, use it)
>>>
>>> This sounds like it needs at least a coordination protocol between the APs?
>>
>> NO, just between the first-hop (homenet) routers. Should work with unchanged
>> of the shelf crap-APs as long as they're attached to a h
16 matches
Mail list logo
