Subject: RE: [seamoby] Comments on CT Reqs draft

From: George Tsirtsis <[email-masked]>
Date: Tue, 14 Aug 2001 18:47:28 -0400

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Tuesday, August 14, 2001 8:09 PM
To: 'George Tsirtsis'; [email-masked]
Cc: Alan O'Neill; Michaela Vanderveen
Subject: RE: [seamoby] Comments on CT Reqs draft

George: 
  Most of these comments seem to be editorial. As you seem 
to have figured out the intended meaning in most cases, I suggest 
that they do make sense to the casual reader. The intent here cannot 
be to define bullet proof requirements (such a document could easily 
consume 100s of pages). 

GT> Sure and that is not my intent. Throughout your comments I see that you
are resisting almost all change and I assume this is because of fear of
opening another endless discussion, which is also not my intent. My only
intent is to have a small number of very clear requirements that I can work
with and develop a protocol that I can also implement.

  More comments below: 
Gary 
> -----Original Message----- 
> From: George Tsirtsis [mailto:[email-masked]] 
> Sent: Tuesday, August 14, 2001 10:19 AM 
> To: [email-masked] 
> Cc: Alan O'Neill; Michaela Vanderveen 
> Subject: [seamoby] Comments on CT Reqs draft 
> 
> 
> All, 
> 
> Here are some comments on the current CT requirements draft. 
> We quote text 
> from the draft to make this easier to read and try to suggest 
> alternative 
> text when possible. 
> 
>  
> 
> Comment 1 
> ----------- 
> "4.9 All context information to be transferred MUST be 
> available at the 
>    AR performing the transfer, prior to the initiation of the context 
>    transfer. 
>  
>    The total context associated with the MN's traffic is composed of 
>    various types of feature context. To effect a rapid transfer, the 
>    context information has to be readily available when the AR begins 
>    the transfer. " 
>  
> This does not make sense as stated. What initiates the 
> gathering of all the 
> relevant context to be transferred? Or you just mean that all relevant 
> context is in close proximity to the CT code (i.e.: same 
> box)? By saying the 
> context MUST be ready when CT is initiated we just defer the 
> potential for 
> delay, we do not eliminate it...i.e.: one may not initiate CT 
> until it has 
> gathered all context but the gathering process could take 
> very long time. 
> We suggest something like the following: 
> "CT should not be slowed down by a process or feature 
> inability to make 
> appropriate context available to CT. CT SHOULD be able to 
> transfer context 
> as it becomes available. 
Your suggestion is syntactically incorrect, and thus harder to understand. 
The intent is as you surmised: to require that the context be at the AR, 
and not elsewhere when the transfer is to be initiated. There are many 
finer points that could be made, but with markedly diminishing importance. 

GT> Gary it does not make sense. My point here is that the requirement
relates to timing considerations which are covered by other requirements in
this spec...weather the context is in or out of the AR it is a mute point
and a protocol should not be held accountable for not doing it this way.

> 
> Comment 2 
> ---------- 
> "4.10 The context information provided for transfer MUST be reliable. 
> 
>    The context to be transferred must not only be readily 
> available for 
>    transfer, but the sending AR must ensure that the 
> information is sound. 
>    
>    The context transfer solution may provide mechanisms to 
> support reliable 
>    transfer of context, but the effectiveness of context transfer in 
> enhancing 
>    handover between ARs would very likely be compromised by 
> attempts to 
>    transfer malformed context." 
> 
> This again makes no sense to the casual reader! How does CT 
> "evaluate" the 
> soundness of a protocol specific context. Consider that the 
> effectiveness of 
> context transfer in enhancing handover between ARs would also 
> very likely be 
> compromised by attempts to ensure that the information is 
> sound. Please 
The requirement says nothing about CT evaluating the soundness 
of the context. The requirement actual says the opposite: that 
the context must itself be reliable, for ct will do nothing to 
compensate for unreliable context. 

GT> I totaly agree with what you state above (which I wish it was the real
text) but the spec says and I repeat "... The context to be transferred must
not only be readily available for transfer, but the sending AR must ensure
that the information is sound." it then also says..."...the effectiveness of
context transfer in  enhancing handover between ARs would very likely be
compromised by attempts to  transfer malformed context". If the requirement
is only about reliability of transfer then that is what it should state.

> remove this totally unreasonable requirement or explain what 
> you mean. If 
It is not unreasonable. It is an absolute requirement, and there 
was general agreement (please refer to the archives for the complete 
discussion). 

GT> No, the requirement is that the CT protocol MUST support reliable
transfer which is fine...it is not about the AR checking the soundness of
the context...the text is confusing.

> people feel strongly about this it should as a minimum be 
> watered down like 
> this: 
> "The sender SHOULD make all reasonable efforts to ensure the 
> data is sound 
> since transfer of invalid data may be more damaging than 
> transfer of no data 
> at all" 
> 

> Comment 3 
> ---------- 
> "5.1.1 The context transfer protocol MUST be capable of 
> transferring all 
>       of the different types of feature context necessary to 
> support the 
>       MN's traffic at a receiving AR." 
> 
> I would like to propose to clarify this further: 
> "CT MUST be generic and feature agnostic, i.e.: CT MUST allow 
> new features 
> to be defined and transported without having to change CT itself." 
This is an entirely different requirement. Your version is trying to 
"future proof" ct. 5.1.1 is concerned with the current features available 
at an AR. Future proof statements such as the one above are, IMHO,
motherhood, 
as everything has to agree, and yet there is no way of ensuring that a 
solution is future proof. 

GT> I do not agree. A number of protocols satisfy the above
requirement..e.g.: diameter. But if you thing that my suggestion is
describing a different requirement then it is clear that I did not
understand 5.1.1. Please illuminate.

> 
> 
> 
> Comment 4 
> ----------- 
> "5.4.1 Proactive context transfer MUST be completed before 
> the handover 
>       of the Mobile Node's traffic to the receiving AR completes." 
> 
> Does this make sense after the removal of the 
> proactive/reactive concept 
> from this doc. Even if it does make sense there is no way to 
> ensure such a 
> thing. You can only try and have mechanisms so you can 
> recover when things 
> go wrong. E.g.: there might not be any connectivity between 
> old and new AR. 
> This is a SHOULD not a MUST. 
I agree. But if you read the minutes of the last IETF meeting, this 
statement will be changed - probably deleted, as "proactive" and "reactive" 
are being removed from the draft. 

GT> That is what I asked first ... and yes I was in the meeting which only
talked about 4.4 and 4.5, hence the question...glad you agree.

> 
> Comment 5 
> ---------- 
> "5.4.3 A context transfer MUST complete with a minimum number 
> of protocol 
>       exchanges between the source AR and the rest of the ARs. " 
> 
> This is a SHOULD..protocol engineering is a trade-off and 
> this is one of the 
> basic variables (signaling level). The requirements document 
> may decair its 
> preference to low signaling levels but must not mandate 
> it...At the end of 
> the day a slightly slower more concrete CT may be better than a faster 
> flakey CT! 
In truth, this is a non-requirement. "minimum" is one of those ambiguous 
words, that cannot be measured without a reference with the requirement 
does not specify. 
In essence, given that the reliability requirements for ct are met (which 
are tbd), then all this requirement says is that there shouldn't be any 
"excess" exchanges. Again, there is no measure to determine what exchanges 
might be "excess". 
Probably the only real application of this requirement is if we end up 
comparing two protocols that are identical in every way but one has more 
exchanges. Might happen. 
At this point, this requirement is unlikely to be deleted, and it has 
no impact as it is stated. 

GT> Why not? You say that this is not really a requirement...yet it is a
MUST in the requirements document.

> 
> 
> Comment 6 
> ----------- 
> "5.4.4 The context transfer protocol design MUST minimize the 
> amount of 
>       processing required at the sending and receiving Access 
> Routers." 
> 
> As above..this is a SHOULD not a MUST...Minimization implies 
> the existence 
> of some optimization function with constraints. Who sets the 
> constraints? If 
> they are set by each implementor according to their fancy, 
> then all these 
> protocols can claim compliance with the above. 
The language could be improved, but the requirement is accurate: 
the protocol MUST not introduce excess processing. You are right, 
the "minimization" requirement has no basis for determining compliance. 

GT> So, again what is the point of mute requirements? get them out of the
way and we will have a much better document.

> 
> 
> Comment 7 
> ----------- 
> "5.4.5 The Context Transfer protocol MUST meet the timing constraints 
>       required by all the feature contexts." 
> 
> Again, CT SHOULD attempt to comply with timing constrains and 
> have ways to 
> recover if it does not...nothing is for certain here...Maybe 
> change with 
> something like this: 
> "The Context Transfer protocol SHOULD strive to comply with 
> the the timing 
> constraints imposed by the different feature contexts. The CT 
> protocol MUST 
> provide ways to recover and allow the handoff to complete 
> normally when the 
> timing constrains are not met." 
Sorry, but if a protocol meets the requirements, whether through 
a clean design or through "recovery", then it meets this requirement. 
"strive" is an anthropomorphic term that doesn't belong in a requirement. 
Also, you have specified two requirements in place of one. 
The requirement remains a MUST. The fact is that everyone one of the 
requirements is likely to fail under some conditions, and the protocol 
is going to have to have some reasonable recovery mechanisms. It would 
take years for us to gain consensus on all the necessary recovery
mechanisms. 

GT> The point is that on one hand there is no way for any protocol to ensure
that timing requirements are met while on the other hand you miss the
obvious requirement of failsafe. BTW, I did not request consensus on the
recovery mechanisms just the requirement for the protocol not to fail the
handoff when it self fails. Then again I would be happy if you changed that
MUST to SHOULD since no one can satisfy the MUST.

> 
> 
> Comment 8 
> ----------- 
> "5.6.2 The context transfer protocol MUST include methods for 
> exchanging 
>       information with the handover process. 
> 
>    Both context transfer and handover require information on the 
>    AR candidates for handover. The context transfer entities 
> may, in the  
>    process of establishing and supporting context transfer, acquire  
>    information that would be useful to the handover process in  
>    determining the new forwarding path: for example, the outcome of an 
>    admission control decision at a receiving AR." 
> 
> 
> The text here is very nebulus, so as a minimum a concrete 
> example should be 
> given.  "For example, if during the CT process one newAR 
> appears to be able 
> to support the MN's QoS requirements better than the other, 
> then CT SHOULD 
> be able to make this information known the handoff process." 
Why? 

GT> Because I give you a valid example that you actually agree with instead
the mumble jumble of the current one but never mind...this is not important
so forget about it.

Here is a good example where the meaning of the requirement was 
in fact clear to you. Are you pre-supposing that other readers have less 
of a grasp of English, or a lower IQ? 

GT> I am not even going to respond to this...you must be very tired since I
do not think you really want to be offensive. I just regret that I am
causing you pain...

As the prime audience for this 
document is actually the people who participated in the writing, it 
would seem reasonable that they would derive the same meaning as you did. 

GT> Gary, a general point. I can understand if I make a point and you
disagree...in which case we have to discuss further. I do not, however,
understand when you agree with me and yet say "....oh no, we can not change
the doc now...too late", unless of course the rest of the group feels the
same way.

- Comments 4, 5, 6 we agree on and unless there are others that disagree we
should change 
- Comment 2 I think we agree on but not sure yet
- Comment 1, 3, 7 we do not seam to agree on
- Comment 8 is not important 

Regards
George

---

From: "Kulwinder Atwal" <[email-masked]>
Date: Tue, 14 Aug 2001 19:43:05 -0400

----- Original Message -----
From: "George Tsirtsis" <[email-masked]>
To: "'Gary Kenward'" <[email-masked]>; <[email-masked]>
Cc: "Alan O'Neill" <[email-masked]>; "Michaela Vanderveen"
<[email-masked]>
Sent: Tuesday, August 14, 2001 6:47 PM
Subject: RE: [seamoby] Comments on CT Reqs draft

> and a protocol should not be held accountable for not doing it this way.

This requirement defines the scope of context transfer protocol.  It states
that the context carried by this protocol will be transferred by this
protocol between Peer Access Routers _only_.  Only the characteristics of
transferring context between Peer Access Routers will be considered in this
protocol.

For example, we have ruled out the transfer of PDP context, and BTS context.

1.  Also, the protocol will not introduce additional messaging to bring in
context from somewhere else.

2.  The time required by some implementations to bring in the context from
somewhere else will not be included in the explicitly or implicitly in the
protocol design.

This requirement does not exclude a _particular_ implementation from storing
the context anywhere it chooses.  It only excludes that implementation
decision from affecting the protocol design.

At least, that is my recollection of the debate on the Design Team.

- Kulwinder.

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 15 Aug 2001 08:59:52 -0400

Hi George,

> with and develop a protocol that I can also implement.

Do you plan to make your implementation of CT public? Same question for FMIPv6?
This would help the community a lot.

Regards,

--
Behcet