headers
Iljitsch van Beijnum | 1 Nov 12:26
Favicon

Re: Crypto-based host identifiers

On 31 okt 2003, at 13:49, Erik Nordmark wrote:

> Another mechanism to limit the exposure by short hashes is
> that the first time a host performs the PK challenge with the peer
> it records the actual public key.

Yes, this is a very good way to handle this. This is what SSH does.

But why stop there if you can simply download *all* site keys and store 
them locally beforehand if you're sufficiently paranoid?
Permalink | Reply | 0 comments |
headers
Iljitsch van Beijnum | 1 Nov 13:34
Favicon

Re: Notes on draft-crocker-mast-analysis-01.txt

On 31 okt 2003, at 13:58, Mark Allman wrote:

> There have been measurement studies conducted (e.g., Partiridge,
> et. al. in Dec/1999 ToN) that show reordering is not as rare as one
> might think.  And, furthermore, it can be fairly significant
> reordering (i.e., not just swapping two packets).

I remember reading a study about reordering on MAE East, which also 
showed considerable reordering. However, IRRC this turned out to be 
mostly due to the parallel processing in the switches that were used. 
Today, router and switch vendors incorporate features to make sure that 
a "session" always flows over a single link. Sometimes it's even 
impossible to turn this off and the definition of a session is such 
that using two or more links in parallel doesn't work in practice 
because (nearly) all traffic is considered part of the same session.

> It seems from reading these few messages I have seen that there are
> really two issues with how reordering affects performance...

>   * Implementation efficiency.  I.e., with reordering we have to
>     hold, manage and process data in the receiver in ways that are
>     different and less efficient (from what I hear) than the
>     techniques used for in-order arrival.  This seems intuitive to
>     me.  (Although, stack implementation is not my forte.)

Yes, processing packets out of order is going to take a bit more time. 
But I believe this is fairly minimal, assuming that upon reception, 
packets are copied to memory where they can sit for a while without 
causing problems. The processing required to handle this is completely 
insignificant compared to interrupt handling, memcopies and checksum
(Continue reading)

Permalink | Reply | 1 comment |
headers
Spencer Dawkins | 1 Nov 13:52
Favicon

Re: Notes on draft-crocker-mast-analysis-01.txt

----- Original Message ----- 
From: "Iljitsch van Beijnum" <iljitsch <at> muada.com>
To: <mallman <at> icir.org>
Cc: "Multi6 Mailing List" <multi6 <at> ops.ietf.org>
Sent: Saturday, November 01, 2003 6:34 AM
Subject: Re: Notes on draft-crocker-mast-analysis-01.txt

> Yes, if this discussion continues we should take it off-list.
However a
> good understanding of TCP is important to multihoming  :-)  so I
> decided to reply on-list this time.

I definitely agree with Iljitsch - Mark, thank you for helping us
improve our understanding of TCP.

Spencer
Permalink | Reply | 0 comments |
headers
Iljitsch van Beijnum | 1 Nov 14:14
Favicon

Re: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00)

On 31 okt 2003, at 14:38, marcelo bagnulo wrote:

>>> The problem is that to detect that there is no route to a certain, 
>>> all
>>> the alternative routes with increasing AS path are tried, which is
>>> inherently slow.

>> Only if there are no alternatives. If there are, the path for those is
>> probably not that long so they show up pretty quickly. Only when the
>> last/only path goes down you'll see the following problem:

> Ok, but this is the case that we care, right?
> From ISPA prespective, there is no longer a route to the destiantion, 
> so the
> multi-homed site detects that and tries the alternative ISP (ISPB).
> So the case that we care is the reconvergence of BGP within the portin 
> of
> the network where a route to the destiantion address no longer exist

No, fortunately it works a bit better than that. Consider:

    ISP A
   /  |  \
X    |    Y
   \  |  /
    ISP B

If X gets transit from both A and B, both A and B will always see the 
path to X over the other. (This is required because if X didn't get 
transit from B but only from A, B would _have_ to reach X over A.) So
(Continue reading)

Permalink | Reply | 0 comments |
headers
Iljitsch van Beijnum | 1 Nov 13:58
Favicon

Re: survivability, rewriting

On 31 okt 2003, at 14:38, marcelo bagnulo wrote:

>> One thing we haven't discussed so far: if upper layers provide us with
>> a hint, what exactly does the multihoming layer do after receiving 
>> such
>> a hint?

> I thought this was what we were discussing with Erik in the Preserving
> established sessiones thread :-)

We may want to do some extra checking before immediately failing over. 
For real time stuff, transport protocols are usually implemented inside 
applications. This means the mh layer may receive far too many hints 
from the transport layer to actually act on each one of them. Also, it 
might be beneficial to find out which alternatives still work before 
selecting them to continue the session over.

I'm thinking along the lines of sending out packets with all possible 
source/dest locator combinations and then see what comes back and how 
fast. Obviously we don't want to set off such a "ping bomb" too often. 
And we very likely don't want to use actual ICMP echos for this, but 
what do we want to use?

> IMHO, i would like to explore alternative approaches first.
> What about when recieving a ULP hint that there is a problem, change 
> both
> source and destiantion locators and send the packet with rewrite ok 
> bit not
> set?
> A more aggresive option would be to send multiple packets in paralel,
(Continue reading)

Permalink | Reply | 12 comments |
headers
marcelo bagnulo | 1 Nov 20:07
Picon

RE: survivability, rewriting

> We may want to do some extra checking before immediately failing over.
> For real time stuff, transport protocols are usually implemented inside
> applications. This means the mh layer may receive far too many hints
> from the transport layer to actually act on each one of them.

Good point.
I guess that the M6 layer will have to react to a hint and then ignore the
next hints for a certain period

> Also, it
> might be beneficial to find out which alternatives still work before
> selecting them to continue the session over.

Ok, but wouldn't this delay the reovery? i.e. the response time would be
worse
(see below)
>
> I'm thinking along the lines of sending out packets with all possible
> source/dest locator combinations and then see what comes back and how
> fast. Obviously we don't want to set off such a "ping bomb" too often.
> And we very likely don't want to use actual ICMP echos for this, but
> what do we want to use?
>
[...]

> Yes. But I don't think we want to do this with actual data packets. In
> fact, there may not be any data packets available when this is
> triggered by a hint.
>
(Continue reading)

Permalink | Reply | 11 comments |
headers
marcelo bagnulo | 1 Nov 20:25
Picon

about draft-ohta-multihomed-isps-00.txt

Hi Masataka,

I wonder, wouldn't this issues be more related to RIR policy than to the
IETF (in particular multi6 wg)?

I mean, if i understand correclty, what it is being proposed in the draft is
somehow similar to what was included in the deprecated aggrgatable global
unicast format (the draft even uses the TLA NLA terminology), and if i
understand correclty, this was decided to be a RIR issue, right?

OTOH, i guess that you are concerned about isp multihoming. IMHO this is a
relevant issue that would be interesting to discuss, but i guess this is not
the appropriate wg for this (considering that it is the SITE multi-homing wg
and that we already have a lot of work to do to make site multihoming work
:-). So perhaps it would be an intersting idea to make an interest list to
discuss this issue without interferring with the work of multi6, what do you
think?

Regards, marcelo
Permalink | Reply | 1 comment |
headers
Iljitsch van Beijnum | 2 Nov 13:07
Favicon

Re: Tentative agenda for Multi6 in Minneapolis

On 31 okt 2003, at 17:14, Kurt Erik Lindqvist wrote:

> 1700-1800 Afternoon Sessions IV

Kurtis, I know the IETF has a long standing tradition of having 
sessions that are relevant to the same broad interest groups overlap, 
but tuesday 17 - 18 hours multi6 overlaps with the ipv6 wg. This seems 
rather insane. Is there anything that can be done about this?
Permalink | Reply | 2 comments |
headers
Tim Chown | 2 Nov 13:29
Picon
Favicon

Re: Tentative agenda for Multi6 in Minneapolis

A good spot Iljitsch - this one has to be fixed.

Tim

On Sun, Nov 02, 2003 at 01:07:28PM +0100, Iljitsch van Beijnum wrote:
> On 31 okt 2003, at 17:14, Kurt Erik Lindqvist wrote:
> 
> >1700-1800 Afternoon Sessions IV
> 
> Kurtis, I know the IETF has a long standing tradition of having 
> sessions that are relevant to the same broad interest groups overlap, 
> but tuesday 17 - 18 hours multi6 overlaps with the ipv6 wg. This seems 
> rather insane. Is there anything that can be done about this?
>
Permalink | Reply | 0 comments |
headers
Dave Crocker | 2 Nov 18:31

Re: I-D ACTION:draft-nordmark-multi6-sim-01.txt (Fwd)

Erik,

EN>         Title           : Strong Identity Multihoming using 128 bit Identifiers (SIM/CBID128)

It would be helpful for the different proposals and specifications to
discussion adoption, administration, use and performance issues, as well as
design rationale.

Your spec has the Protocol Walthrough, which gives detail about some of the
usage effort. Explicit discussion about the critical adoption requirements
would be particularly helpful.

I am probably not reading the specification correctly, but it appears that SIM
requires:

ADOPTION

1. Modification to both endpoints, using a shim layer directly above IP

2. Addition of a DNS record type and expected modification of DNS servers, to
do differential processing, based on presence or absence of records of that
type, when a query for that record type is made

3. Modification of intermediate routers, to do locator re-writing.

DESIGN

As the spec notes, deferred validation of new locators adds complexity to the
protocol.
(Continue reading)

Permalink | Reply | 2 comments |

Gmane