Subject: RE: [dhcwg] FW: I-D ACTION:draft-volz-dhc-rapidreply-opt-00.txt

From: "Kostur, Andre" <[email-masked]>
Date: Thu, 6 Nov 2003 10:27:51 -0800

Offhand I'm thinking that a Rapid Commit option would be handy, particularly
in environments that may have a large number of devices attempting to
Discover simultaneously.  However I would suggest that the draft specify
that by default DHCP Servers SHOULD have Rapid Reply disabled.

Oh, and a minor comment: I think the option should be renamed to be "Rapid
Commit" instead of Rapid Reply to be consistent with DHCPv6 (which is the
inspiration of this option).
 
> -----Original Message-----
> From: Bernie Volz [mailto:[email-masked]]
> Sent: Thursday, November 06, 2003 6:26 AM
> To: [email-masked]; [email-masked]
> Subject: RE: [dhcwg] FW: I-D 
> ACTION:draft-volz-dhc-rapidreply-opt-00.txt
> 
> 
> Barr:
> 
> These are good questions and should be addressed. I don't 
> have any specific
> case where the Rapid Reply is really desired. As far as 
> restrictions, I
> would expect any migration would be slow (because of the 
> large deployed
> client base) and servers should be configurable as to whether 
> they allow it
> to be used - such as in cases where multiple servers exist 
> (though coupled
> with failover, this option could be very useful to expedite 
> configuration).
> Regarding an updated state diagram and processing 
> description, we should
> provide that (though there are others that have indicated 
> they'd rather not
> have state diagrams).
> 
> Daniel will present this work at the DHC WG meeting next week 
> and we'll
> revise the draft with that input and any Mailing List input 
> (such as yours).
> This assumes that the general consensus is work should 
> continue on this.
> 
> - Bernie
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Barr
> Hibbs
> Sent: Thursday, November 06, 2003 12:35 AM
> To: [email-masked]
> Subject: RE: [dhcwg] FW: I-D 
> ACTION:draft-volz-dhc-rapidreply-opt-00.txt
> 
> 
> Daniel, Bernie--
> 
> is there sufficient demand for a DHCPv4 solution to highly 
> mobile devices
> that this option is necessary?  I don't object to this 
> proposed option, but
> I do wonder if a DHCPv4 solution is merely a stopover on the 
> road to DHCPv6?
> 
> Is there any benefit to somehow restricting its use to avoid 
> a large-scale
> migration from the Discover-Offer-Request-Ack cycle to the abbreviated
> exchange?  Should we be developing what I see as an alternative to
> Mobile-IP?
> 
> I'd like to see an updated client state transition diagram 
> showing this
> exchange and updated message required field and option content tables
> covering the DHCPDISCOVER and DHCPACK message changes when 
> you update the
> draft.
> 
> --Barr
> 
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 
> 
> 
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg
>

---

From: Soohong Daniel Park <[email-masked]>
Date: Fri, 07 Nov 2003 17:08:23 +0900

Hello Kostur

Offhand I'm thinking that a Rapid Commit option would be handy,
particularly in environments that may have a large number of devices
attempting to Discover simultaneously.  However I would suggest that the
draft specify that by default DHCP Servers SHOULD have Rapid Reply
disabled.

=> typo disabled / enabled  correct ?

Oh, and a minor comment: I think the option should be renamed to be
"Rapid Commit" instead of Rapid Reply to be consistent with DHCPv6
(which is the inspiration of this option).

=> interesting. originally I tried to distinguish this option from
option of dhcpv6. I will consider it.

Regards

Daniel (Soohong Daniel Park)
Mobile Platform Laboratory, SAMSUNG Electronics

---

From: "Kostur, Andre" <[email-masked]>
Date: Fri, 7 Nov 2003 07:34:47 -0800

No, I actually meant disabled.  Recall that DHCP was designed to work in a
scenario where there are multiple DHCP servers performing offers to clients.
Rapid Commit/Reply is basically a feature where you tell the service that
there isn't multiple DHCP servers (changing the default assumption in the
protocol).

So... by default all DHCP servers will work properly in a multi-server
environment unless it is explicitly told that it is the only server that
will be answering (where "only" may include load-balanced and/or failover
enabled pairs).

-----Original Message-----
From: Soohong Daniel Park [mailto:[email-masked]]
Sent: Friday, November 07, 2003 12:08 AM
To: 'Kostur, Andre'; 'Bernie Volz'; [email-masked]; [email-masked]
Cc: 'Soohong Daniel Park'
Subject: RE: [dhcwg] FW: I-D ACTION:draft-volz-dhc-rapidreply-opt-00.txt

Hello Kostur
=> interesting. originally I tried to distinguish this option from option of
dhcpv6. I will consider it.

Regards

---

From: Markus Rentschler <[email-masked]>
Date: Fri, 7 Nov 2003 10:57:42 +0100

I see the Rapid Reply/Commit Option as a useful thing and support what is said below.

Best Regards,
             Markus

-----Ursprungliche Nachricht-----
Von:	Soohong Daniel Park [SMTP:[email-masked]]
Gesendet am:	Freitag, 7. November 2003 09:08
An:	'Kostur, Andre'; 'Bernie Volz'; [email-masked]; [email-masked]
Cc:	'Soohong Daniel Park'
Betreff:	RE: [dhcwg] FW: I-D ACTION:draft-volz-dhc-rapidreply-opt-00.txt

> 
> ----------
> From: 	Soohong Daniel Park[SMTP:[email-masked]]
> Sent: 	Friday, November 07, 2003 9:08:23 AM
> Auto forwarded by a Rule
Hello Kostur

Regards

 << Datei: ATT00002.htm >>

---

From: "soohong park" <[email-masked]>
Date: Mon, 10 Nov 2003 04:03:05 +0900

Hello Stephane

>It is a good idea, dhcp is ok to give IP addressses in the wireless 
>environment

Yep

>but it is not optimised for mobility!

"supported for mobility" would be better than optimised.

Correct ?

Regards

_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*  
http://join.msn.com/?page=features/junkmail

---

From: "soohong park" <[email-masked]>
Date: Mon, 10 Nov 2003 08:22:39 +0900

Hello Greg

Sorry for my delaying

>I'm afraid I'm not (yet) familiar with the IPv6 rapid reply mechanism
>and I'm only slowly coming up to speed on some of DHC drafts that are
>out there.

IPv6 is rapid commit option and IPv4 is rapid reply option (temporary)

>Could you please clarify what sort of environment needs this mechanism ?

1) For getting IP address and configuration information faster ! (especially 
in wireless environment)

2) Reducing the latency when performing address assignment.
As Kostur said in previous mail, a Rapid Reply option would be handy, 
particularly in environments that may have a large number of devices 
attempting to Discover simultaneously.

If failover is used, you have redundancy because there are multiple servers. 
And, Rapid Reply can be used with failover servers because they already have 
a facility to balance the load and decide which clients each server will 
respond to - hence, in failover mode a client won't be assigned two
addresses (one by each server). So, with failover and Rapid Reply, you have 
fast address assignment (2 message exchange), no wasted addresses (a client 
is not assigned multiple addresses), and redundancy.

I hope this is what you wanted clarification on.

>In well set up dhcp environments the entire 4-message dhcp exchange can
>be done in under 1 second, or at most a few seconds. Maybe the
>environments you are working with do not have this behavior.

2-message exchange instead of 4-message. I think it can support for mobility 
as well.

Regards

_________________________________________________________________
Add photos to your messages with MSN 8. Get 2 months FREE*. 
http://join.msn.com/?page=features/featuredemail

---

From: "soohong park" <[email-masked]>
Date: Mon, 10 Nov 2003 08:10:47 +0900

Hello Kostur

==> I definitely understand your mention, sorry for my misunderstanding.

==>Exactly, I will consider it in the next draft

Regards

_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*. 
http://join.msn.com/?page=features/featuredemail