RE: review of draft-ietf-shim6-failure-detection-03.txt

[Sam Xia <xiazhongqi@huawei.com>]

Hi, Jari,
   some further discussion inline:

 Best Regards, Sam Xia 

> -----Original Message-----
> From: owner-shim6@psg.com [mailto:owner-shim6@psg.com] On 
> Behalf Of Jari Arkko
> Sent: Monday, June 26, 2006 6:13 PM
> To: Sam Xia
> Cc: 'Iljitsch van Beijnum'; 'shim6-wg'
> Subject: Re: review of draft-ietf-shim6-failure-detection-03.txt
> 
> Hi Sam,
> 
> And thanks your comments! Some further discussion inline:
> 
> >    As for section 6.4 (behaviour), maybe it is a better 
> specification 
> >form to seperate the text explaination and move them to the 
> >corresponding the state machine section. Then reader can easily 
> >understand what the draft says.
> >  
> >
> I have merged the description and the state machine in version -05.
> Lets see if you like it better.
> 
> >   And why do you think it is suitable to define the value for send 
> >timer and alive timer as 10s and 3s?
> >  
> >
> The first of these reflects the timeframe under which Shim6 
> attempts to recover from a perceived problem. It can not be 
> too long (e.g. minutes) because otherwise recovery would not 
> be useful for existing sessions.
> But it can not be too short either, because temporary 
> glitches would cause unnecessary Shim6 activity.
> 
> The second timer reflects the need to send keepalive messages 
> under a specific situation (one-way traffic) such that we get 
> feedback on whether recovery should be started on not.
> 
> Its clear that experimentation with suitable values will be 
> needed, as well as dynamic adjustments. But we've tried to 
> avoid specifying too many mechanisms for now, until we get 
> implementation and deployment experience.

Yes, I agree. The actual value for these timers should be tested in the real
experimentation. And they should be tuned according to experimentation
result. 
Anyway, to add more texts describing how to determine the value is good. For
example, there is a keepalive option for TCP connection; the draft should
address
how these timer value imposes TCP connection. And the interactions between
these timers and other tranportation layer protocols should be studied
further.


> 
> >  In my opinion, introduction of shim6 to ipv6 has add the 
> complexity 
> >of ip layer very much; and shim6-failure-detection is not simple. I 
> >don't know what is the last performance.
> >  
> >
> It does add complexity, yes. The questions though are if (a) 
> this complexity is a smaller price to pay than the pain from 
> having no multihoming or the complexity from other, 
> alternative solutions, and (b) whether there is something 
> that we could do to reduce complexity.
> 
> On point b, I'm not sure there is a lot we can do. At least 
> not without revisiting some of the requirement decisions, 
> such as the need to support at least some scenarios where 
> there's only unidirectional connectivity.
> 
> Thoughts?
> 
> --Jari
> 
> 
>