Subject: Shim6 Working Group Last call on the Shim6 Document Set
From: Geoff Huston <[email-masked]>
To: [email-masked]
Cc: [email-masked], Jari Arkko <[email-masked]>, Iljitsch van Beijnum <[email-masked]>, Marcelo bagnulo braun <[email-masked]>, Erik Nordmark <[email-masked]>, [email-masked]
Date: Mon, 25 Jun 2007 10:25:18 +1000

Hi,

This note starts the WG Last Call for comments on the three "base" Shim6 
documents as Proposed Standards:

draft-ietf-shim6-proto-08.txt
              "Level 3 multihoming shim protocol"

draft-ietf-shim6-hba-03.txt
              "Hash Based Addresses (HBA)"

draft-ietf-shim6-failure-detection-08.txt
              "Failure Detection and Locator Pair
               Exploration Protocol for IPv6 

               Multihoming"

These documents can be found at:
   http://www.ietf.org/internet-drafts/draft-ietf-shim6-proto-08.txt
   http://www.ietf.org/internet-drafts/draft-ietf-shim6-hba-03.txt
 
http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure-detection-08.txt

Please review the documents carefully, and send your feedback to the 
SHIM6 list.
Please also indicate whether or not you believe that these documents are 
ready to
go to the IESG for publication as a set of Proposed Standards.

This Working Group Last Call will end in two weeks, on the 9th July 2007 at
1100, UTC+10

    Thanks,

          Geoff & Kurtis

Delivery-date: Thu, 14 Jun 2007 13:30:52 +0000
Date: Thu, 14 Jun 2007 15:30:19 +0200
From: Matthijs Mekking <[email-masked]>
Subject: Re: Some small remarks for REAP
To: Brian E Carpenter <[email-masked]>, [email-masked]
Organization: NLnet Labs

Brian E Carpenter schreef:
> ...without shim6. So while it's always a bad thing to lose packets, I 
> don't
> see this as a fatal problem.
>>
>> 2.
>> How much locators will a host use? Because the Shim6 context will be 
>> garbage collected after 5 minutes (according to 
>> draft-ietf-shim6-proto-08) and with the proposed constant values, 
>> only a maximum of fifteen different address pairs can be probed. In 
>> reality, this number will be smaller, since the ULP will probably 
>> time out after two minutes. So, if only two or three locators per 
>> host are going to be used, these constants seem to work fine. With 
>> more locators, the protocol will probably also work fine, but a host 
>> will maintain locators that are probably not going to be probed. That 
>> seems a bit inefficient.
>
> Which case do we want to optimize? A site that has a likely number of
> ISPs such as two or three, or a site that for some strange reason has 
> more?
>
> (I don't count the case of a highly virtualized host that has many
> virtual interface identifiers, because each virtual stack will
> need its own shim6 context anyway.)
>
>    Brian

Never said they were fatal problems, just thought they were worth 
mentioning ;-). About the second remark. I did not foresee how much 
locators a host is going to use. But if it is more than three, the 
interval between probing must be increased at lower rate (lower than 
doubling it), or some locators will never be probed.

Regards,

Matthijs Mekking

Delivery-date: Thu, 14 Jun 2007 13:26:21 +0000
Date: Thu, 14 Jun 2007 15:23:49 +0200
From: Matthijs Mekking <[email-masked]>
Subject: Re: Some small remarks for REAP
To: marcelo bagnulo braun <[email-masked]>, [email-masked]
Organization: NLnet Labs

Hi,

How unfortunate: I explained the unidirectional flow incorrectly: I 
meant: A may still receive messages, but its payload will not be 
delivered to B.
Anyway, I think I misunderstood the multiple keepalives part. I thought 
that receiving one payload packet triggered the replying of multiple 
keepalive packets.
If so, than I think the first remark is no issue.

Regards,

Matthijs Mekking

marcelo bagnulo braun schreef:
> Hi Matthijs,
>
> thanks for the comments on the draft... see replies in line...
>
> El 11/06/2007, a las 18:30, Matthijs Mekking escribió:
>
>> Hello,
>>
>> I looked at draft-ietf-shim6-failure-detection-07, and want to make 
>> two remarks.
>>
>> 1.
>> The draft states that "FBD works by generating REAP keepalives if the 
>> node is receiving packets from its peer but not sending any of its own."
>> Suppose we have two hosts A and B, and A is sending payload packets 
>> to B (unidirectional). B will respond with REAP keepalive messages. 
>> But suppose a link failure occurs: A cannot receive any messages, but 
>> is still able to send. A will continue sending payload packets
>
> I don't think so....
>
> A is sending data packet to B
> Hence B is sending keepalives to A
>
> Suppose there is a failure in the path that only affects the direction 
> from B to A
>
> This is the scenario that you are suggesting right?
>
> If this happens, A will no longer receive keepalive packets, so it 
> will detect a failure and will start the exploration procedure, after 
> wich a new path will be found and used
>
>
>
>
>> and might receive (delayed) keepalive messages that were triggered 
>> from payload data before the link failure.
>
>
> yes but at some point the delayed keepalive will be over and A will no 
> longer receive keepalive packet and will detect the failure..
>
>>  Now the payload sent after the link failure is lost without being 
>> noticed. This occurs because keepalives cannot be related to the 
>> transmitted payload.
>>
>
> Note that basically this relates to the TSend timer. You can play with 
> it so that the detection is really fast (but it implies more keepalive 
> traffic)
>
> There are a couple of research papers that study the behaviour of the 
> REAP protocol and its reaction capabilities in the different scenarios 
> and the result is basically a tradeoff between the keepalive frequency 
> and the recovery time.
>
>> This will not be a problem if you run a reliable protocol like TCP on 
>> top of it, because in that case TCP will fetch this problem. But if 
>> UDP is used, this remains an issue I think.
>>
>
> sure, but reap is a IP layer protocol and i guess it is better not to 
> link it to transport layer information
>
>> Example scenario: Unidirectional traffic from A to B using address 
>> pair (A1, B1):
>> ---------------------------------------------------------------------------------------------------------------------------------------- 
>>
>> (1) A --> B: Payload1 (A1, B1)
>> (2) B --> A: Keepalive1 (B1, A1)
>> (3) B --> A: Keepalive1 (B1, A1)
>>
>
> not really... the state machine is per packet, i don't think it will 
> be possible to have two keepalives triggered with a single data packet 
> (it is possible the oposite situation, one keepalive for multiple data 
> packets)
>
>> Link failure (A1, B1)
>>
>
> my undersrtanding from the previous text was the the failure affected 
> only the direction from B to A...?
>
>> (1) A --> B: Payload2 (A1, B1) (will fail)
>
> see previous comment
>
>> (1) A --> B: Keepalive1 (B1, A1)
>
> why would A send a keepalive, since:
> first, A is sending data packets
> second, A has not received a data packet
>
> I mean, keepalives are generated when a node is not generating data 
> packets with a high enough frequency and it is receeiving data packets 
> from the other end,m which is exactly the oposite situation than A in 
> your example
>
>> ---------------------------------------------------------------------------------------------------------------------------------------- 
>>
>>
>>
>> 2.
>> How much locators will a host use? Because the Shim6 context will be 
>> garbage collected after 5 minutes (according to 
>> draft-ietf-shim6-proto-08) and with the proposed constant values, 
>> only a maximum of fifteen different address pairs can be probed.
>
>
> A shim6 node will collect garbage when the context is no longer being 
> used by any upper layer, so if there is an open socket then this 5 min 
> limit will not apply. Bottom line is that in the case that there is a 
> failure, it is likely imho that the shim6 layer will be able to know 
> locally that there is an upper layer that is using the shim6 state, so 
> the shim6 layer won't start the 5 min garbage collection timer
>
> in particular, if the context is in epxloration state, it needs first 
> to give up the exploration phase and then launch the 5 min garbage 
> collection timer....
>
>>  In reality, this number will be smaller, since the ULP will probably 
>> time out after two minutes. So, if only two or three locators per 
>> host are going to be used, these constants seem to work fine. With 
>> more locators, the protocol will probably also work fine, but a host 
>> will maintain locators that are probably not going to be probed. That 
>> seems a bit inefficient.
>>
>
> as i mention above, i don't think the garbage collection timer will 
> limit the number of locators that can be explored.
>
> besides the reap spec does not determines the number of locator pairs 
> that can be probed simoultaneously, so more aggressive behaviours that 
> probing a single pair at the time are acceptable in cases where many 
> locator pairs are availbale.
>
> Regards, marcelo
>
>
>> What is your opinion about these two subjects?
>>
>>
>>
>> Regards,
>>
>> Matthijs Mekking
>>
>
>

Delivery-date: Tue, 12 Jun 2007 09:32:47 +0000
Date: Tue, 12 Jun 2007 19:33:22 +1000
From: Geoff Huston <[email-masked]>
To: Brian E Carpenter <[email-masked]>
Cc: Matthijs Mekking <[email-masked]>, [email-masked]
Subject: Re: Some small remarks for REAP

Brian E Carpenter wrote:
> Matthijs,
> 
> On 2007-06-11 18:30, Matthijs Mekking wrote:
>> Hello,
>>
>> I looked at draft-ietf-shim6-failure-detection-07, and want to make 
>> two remarks.
>>
>> 1.
>> The draft states that "FBD works by generating REAP keepalives if the 
>> node is receiving packets from its peer but not sending any of its own."
>> Suppose we have two hosts A and B, and A is sending payload packets to 
>> B (unidirectional). B will respond with REAP keepalive messages. But 
>> suppose a link failure occurs: A cannot receive any messages, but is 
>> still able to send. A will continue sending payload packets and might 
>> receive (delayed) keepalive messages that were triggered from payload 
>> data before the link failure. Now the payload sent after the link 
>> failure is lost without being noticed. This occurs because keepalives 
>> cannot be related to the transmitted payload.
>>
>> This will not be a problem if you run a reliable protocol like TCP on 
>> top of it, because in that case TCP will fetch this problem. But if 
>> UDP is used, this remains an issue I think.
> 
> UDP is an unreliable protocol by definition, so a burst of unnotified
> loss is not a protocol violation. Also, shim6 is supposed to respect the
> 'first, do no harm' principle - i.e. not produce *worse* behaviour than
> without shim6. So while it's always a bad thing to lose packets, I don't
> see this as a fatal problem.

Brian is right - what would've happened _without_ shim6 in the stack 
would've been that A would continue to send into the void, as this is, 
as you describe it, a unidirectional flow. So in the case of shim6 in 
the stack there will still be a period before the shim6 protocol element 
detects the failure and attempts to repair it.

>> 2.
>> How much locators will a host use?

for itself or for others?

For itself - as many as it has local addresses. For others then as many 
as it has shim6 active state for,

>> Because the Shim6 context will be 
>> garbage collected after 5 minutes (according to 
>> draft-ietf-shim6-proto-08) and with the proposed constant values, only 
>> a maximum of fifteen different address pairs can be probed. In 
>> reality, this number will be smaller, since the ULP will probably time 
>> out after two minutes.

well this timer depends on the ULP of course.

>> So, if only two or three locators per host are 
>> going to be used, these constants seem to work fine. With more 
>> locators, the protocol will probably also work fine, but a host will 
>> maintain locators that are probably not going to be probed. That seems 
>> a bit inefficient.
> 
> Which case do we want to optimize? A site that has a likely number of
> ISPs such as two or three, or a site that for some strange reason has more?

the protocol as described is deliberately cautious in the way in which 
it manages locator exploration, and the optimisation is around the 2 - 3 
locators in the a set rather than attempting to explore across a few 
hundred or more in a limited time..

Geoff

Delivery-date: Tue, 12 Jun 2007 09:09:25 +0000
Cc: [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Some small remarks for REAP
Date: Tue, 12 Jun 2007 11:08:30 +0200
To: Matthijs Mekking <[email-masked]>

Hi Matthijs,

thanks for the comments on the draft... see replies in line...

El 11/06/2007, a las 18:30, Matthijs Mekking escribi=F3:

> Hello,
>
> I looked at draft-ietf-shim6-failure-detection-07, and want to make =20=

> two remarks.
>
> 1.
> The draft states that "FBD works by generating REAP keepalives if the =20=

> node is receiving packets from its peer but not sending any of its =20
> own."
> Suppose we have two hosts A and B, and A is sending payload packets to =
=20
> B (unidirectional). B will respond with REAP keepalive messages. But =20=

> suppose a link failure occurs: A cannot receive any messages, but is =20=

> still able to send. A will continue sending payload packets

I don't think so....

A is sending data packet to B
Hence B is sending keepalives to A

Suppose there is a failure in the path that only affects the direction =20=

from B to A

This is the scenario that you are suggesting right?

If this happens, A will no longer receive keepalive packets, so it will =20=

detect a failure and will start the exploration procedure, after wich a =20=

new path will be found and used

> and might receive (delayed) keepalive messages that were triggered =20
> from payload data before the link failure.

yes but at some point the delayed keepalive will be over and A will no =20=

longer receive keepalive packet and will detect the failure..

>  Now the payload sent after the link failure is lost without being =20
> noticed. This occurs because keepalives cannot be related to the =20
> transmitted payload.
>

Note that basically this relates to the TSend timer. You can play with =20=

it so that the detection is really fast (but it implies more keepalive =20=

traffic)

There are a couple of research papers that study the behaviour of the =20=

REAP protocol and its reaction capabilities in the different scenarios =20=

and the result is basically a tradeoff between the keepalive frequency =20=

and the recovery time.

> This will not be a problem if you run a reliable protocol like TCP on =20=

> top of it, because in that case TCP will fetch this problem. But if =20=

> UDP is used, this remains an issue I think.
>

sure, but reap is a IP layer protocol and i guess it is better not to =20=

link it to transport layer information

> Example scenario: Unidirectional traffic from A to B using address =20
> pair (A1, B1):
> =
-----------------------------------------------------------------------=20=

> -----------------------------------------------------------------
> (1) A --> B: Payload1 (A1, B1)
> (2) B --> A: Keepalive1 (B1, A1)
> (3) B --> A: Keepalive1 (B1, A1)
>

not really... the state machine is per packet, i don't think it will be =20=

possible to have two keepalives triggered with a single data packet (it =20=

is possible the oposite situation, one keepalive for multiple data =20
packets)

> Link failure (A1, B1)
>

my undersrtanding from the previous text was the the failure affected =20=

only the direction from B to A...?

> (1) A --> B: Payload2 (A1, B1) (will fail)

see previous comment

> (1) A --> B: Keepalive1 (B1, A1)

why would A send a keepalive, since:
first, A is sending data packets
second, A has not received a data packet

I mean, keepalives are generated when a node is not generating data =20
packets with a high enough frequency and it is receeiving data packets =20=

from the other end,m which is exactly the oposite situation than A in =20=

your example

> =
-----------------------------------------------------------------------=20=

> -----------------------------------------------------------------
>
>
> 2.
> How much locators will a host use? Because the Shim6 context will be =20=

> garbage collected after 5 minutes (according to =20
> draft-ietf-shim6-proto-08) and with the proposed constant values, only =
=20
> a maximum of fifteen different address pairs can be probed.

A shim6 node will collect garbage when the context is no longer being =20=

used by any upper layer, so if there is an open socket then this 5 min =20=

limit will not apply. Bottom line is that in the case that there is a =20=

failure, it is likely imho that the shim6 layer will be able to know =20
locally that there is an upper layer that is using the shim6 state, so =20=

the shim6 layer won't start the 5 min garbage collection timer

in particular, if the context is in epxloration state, it needs first =20=

to give up the exploration phase and then launch the 5 min garbage =20
collection timer....

>  In reality, this number will be smaller, since the ULP will probably =20=

> time out after two minutes. So, if only two or three locators per host =
=20
> are going to be used, these constants seem to work fine. With more =20
> locators, the protocol will probably also work fine, but a host will =20=

> maintain locators that are probably not going to be probed. That seems =
=20
> a bit inefficient.
>

as i mention above, i don't think the garbage collection timer will =20
limit the number of locators that can be explored.

besides the reap spec does not determines the number of locator pairs =20=

that can be probed simoultaneously, so more aggressive behaviours that =20=

probing a single pair at the time are acceptable in cases where many =20
locator pairs are availbale.

Regards, marcelo

> What is your opinion about these two subjects?
>
>
>
> Regards,
>
> Matthijs Mekking
>

Delivery-date: Tue, 12 Jun 2007 08:18:20 +0000
Date: Tue, 12 Jun 2007 10:16:08 +0200
From: Brian E Carpenter <[email-masked]>
To: Matthijs Mekking <[email-masked]>
CC:  [email-masked]
Subject: Re: Some small remarks for REAP

Matthijs,

On 2007-06-11 18:30, Matthijs Mekking wrote:
> Hello,
> 
> I looked at draft-ietf-shim6-failure-detection-07, and want to make two 
> remarks.
> 
> 1.
> The draft states that "FBD works by generating REAP keepalives if the 
> node is receiving packets from its peer but not sending any of its own."
> Suppose we have two hosts A and B, and A is sending payload packets to B 
> (unidirectional). B will respond with REAP keepalive messages. But 
> suppose a link failure occurs: A cannot receive any messages, but is 
> still able to send. A will continue sending payload packets and might 
> receive (delayed) keepalive messages that were triggered from payload 
> data before the link failure. Now the payload sent after the link 
> failure is lost without being noticed. This occurs because keepalives 
> cannot be related to the transmitted payload.
> 
> This will not be a problem if you run a reliable protocol like TCP on 
> top of it, because in that case TCP will fetch this problem. But if UDP 
> is used, this remains an issue I think.

UDP is an unreliable protocol by definition, so a burst of unnotified
loss is not a protocol violation. Also, shim6 is supposed to respect the
'first, do no harm' principle - i.e. not produce *worse* behaviour than
without shim6. So while it's always a bad thing to lose packets, I don't
see this as a fatal problem.

> 
> Example scenario: Unidirectional traffic from A to B using address pair 
> (A1, B1):
> ---------------------------------------------------------------------------------------------------------------------------------------- 
> 
> (1) A --> B: Payload1 (A1, B1)
> (2) B --> A: Keepalive1 (B1, A1)
> (3) B --> A: Keepalive1 (B1, A1)
> 
> Link failure (A1, B1)
> 
> (1) A --> B: Payload2 (A1, B1) (will fail)
> (1) A --> B: Keepalive1 (B1, A1)
> ---------------------------------------------------------------------------------------------------------------------------------------- 
> 
> 
> 
> 2.
> How much locators will a host use? Because the Shim6 context will be 
> garbage collected after 5 minutes (according to 
> draft-ietf-shim6-proto-08) and with the proposed constant values, only a 
> maximum of fifteen different address pairs can be probed. In reality, 
> this number will be smaller, since the ULP will probably time out after 
> two minutes. So, if only two or three locators per host are going to be 
> used, these constants seem to work fine. With more locators, the 
> protocol will probably also work fine, but a host will maintain locators 
> that are probably not going to be probed. That seems a bit inefficient.

Which case do we want to optimize? A site that has a likely number of
ISPs such as two or three, or a site that for some strange reason has more?

(I don't count the case of a highly virtualized host that has many
virtual interface identifiers, because each virtual stack will
need its own shim6 context anyway.)

    Brian

Delivery-date: Mon, 11 Jun 2007 14:31:21 +0000
Date: Mon, 11 Jun 2007 18:30:51 +0200
From: Matthijs Mekking <[email-masked]>
Subject: Some small remarks for REAP
To: [email-masked]

Hello,

I looked at draft-ietf-shim6-failure-detection-07, and want to make two 
remarks.

1.
The draft states that "FBD works by generating REAP keepalives if the 
node is receiving packets from its peer but not sending any of its own."
Suppose we have two hosts A and B, and A is sending payload packets to B 
(unidirectional). B will respond with REAP keepalive messages. But 
suppose a link failure occurs: A cannot receive any messages, but is 
still able to send. A will continue sending payload packets and might 
receive (delayed) keepalive messages that were triggered from payload 
data before the link failure. Now the payload sent after the link 
failure is lost without being noticed. This occurs because keepalives 
cannot be related to the transmitted payload.

This will not be a problem if you run a reliable protocol like TCP on 
top of it, because in that case TCP will fetch this problem. But if UDP 
is used, this remains an issue I think.

Example scenario: Unidirectional traffic from A to B using address pair 
(A1, B1):
----------------------------------------------------------------------------------------------------------------------------------------
(1) A --> B: Payload1 (A1, B1)
(2) B --> A: Keepalive1 (B1, A1)
(3) B --> A: Keepalive1 (B1, A1)

Link failure (A1, B1)

(1) A --> B: Payload2 (A1, B1) (will fail)
(1) A --> B: Keepalive1 (B1, A1)
----------------------------------------------------------------------------------------------------------------------------------------

2.
How much locators will a host use? Because the Shim6 context will be 
garbage collected after 5 minutes (according to 
draft-ietf-shim6-proto-08) and with the proposed constant values, only a 
maximum of fifteen different address pairs can be probed. In reality, 
this number will be smaller, since the ULP will probably time out after 
two minutes. So, if only two or three locators per host are going to be 
used, these constants seem to work fine. With more locators, the 
protocol will probably also work fine, but a host will maintain locators 
that are probably not going to be probed. That seems a bit inefficient.

What is your opinion about these two subjects?

Regards,

Matthijs Mekking