Subject: [dhcwg] Bulk Leasequery for DHCPv6

From: Mark Stapp <[email-masked]>
Date: Mon, 15 Oct 2007 14:08:34 -0400

Hello, all,

I've just submitted a new draft proposing a TCP-based leasequery for 
DHCPv6. This is sort of a follow-on after the discussion in the WG that 
led to the simplification of the current UDP-based leasequery in 
rfc5007. Those discussions removed some elements of leasequery for v6 
that had tried to use UDP to manage large result sets. There were folks 
who felt that those elements were awkward, and overly complicated the 
core query protocol. This new draft is an attempt to specify some 
extensions to the leasequery protocol and use TCP as the transport in 
order to support large result sets.

I'd be very happy to hear feedback about the draft, and I'm planning to 
ask that it become a WG draft eventually.

Here's a url:

http://www.ietf.org/internet-drafts/draft-stapp-dhc-dhcpv6-bulk-leasequery-00.txt

Thanks,
Mark

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Marcus Goller" <[email-masked]>
Date: Tue, 16 Oct 2007 11:09:00 +0200

Hi,

After a first quick read through, this sounds like a useful extension to the
existing Leasequery mechanism. Would you mind quickly summarizing the
reasons why supporting this with UDP queries would make the protocol too
complicated?
I agree that TCP is probably the better choice, but I would at least like to
see UDP as an optional transport mechanism. The reason for this is that I am
not convinced that protocol specific options (query types) should be
dependent on the underlying transport protocol. The requestor should be able
to choose the appropriate protocol. But I might underestimate the impact to
the existing UDP based Leasequery specification, so any additional
information would be appreciated.

Regards,

Marcus

---

From: Mark Stapp <[email-masked]>
Date: Tue, 16 Oct 2007 10:53:59 -0400

Hello Marcus,

thanks for the rapid response!

a sketch of the history sort of goes like this: the early v6 leasequery 
drafts did include semantics allowing for queries that could return 
multiple/many results. during the WG discussion, there was some feeling 
that trying to do that in UDP was making the leasequery protocol overly 
complicated, trying to deal with marshalling, retransmission, etc. and 
so the 'bulk' capability was taken out of what has become RFC5007. [if 
I'm misrepresenting this, I hope someone will correct me.]

but there are some situations (that I try to describe in the new draft) 
where a 'bulk' or 'one query, many results' capability may be very 
useful. so I've tried to work out what a TCP-based protocol would look 
like, mainly trying to extend the concepts that were introduced in RFC5007.

I do agree that one of the weaknesses in this first version of this 
'bulk' draft is that there's no really tight language about the 
relationship between the new queries and the existing UDP protocol. I 
hope that that'll improve with WG input, as folks help decide how to 
draw the lines between the two versions. personally, I think that 
allowing the UDP queries in the TCP version should be fine. but there 
isn't really any good way to deliver thousands of results in the UDP 
version, so I don't think it's going to be worth much to try to permit 
the use of 'bulk' queries in UDP.

Thanks,
Mark

Marcus Goller wrote:
> Hi,
> 
> After a first quick read through, this sounds like a useful extension to 
> the existing Leasequery mechanism. Would you mind quickly summarizing 
> the reasons why supporting this with UDP queries would make the protocol 
> too complicated?
> I agree that TCP is probably the better choice, but I would at least 
> like to see UDP as an optional transport mechanism. The reason for this 
> is that I am not convinced that protocol specific options (query types) 
> should be dependent on the underlying transport protocol. The requestor 
> should be able to choose the appropriate protocol. But I might 
> underestimate the impact to the existing UDP based Leasequery 
> specification, so any additional information would be appreciated.
> 
> Regards,
> 
> Marcus
> 
>

---

From: "Marcus Goller" <[email-masked]>
Date: Tue, 16 Oct 2007 17:37:14 +0200

Hi Mark,

I agree that allowing the UDP based queries on TCP should be possible, the
other way round might have more of an impact.

Another option, in my opinion, would be to introduce an new status code
("UnsupportedTransportLayer" or something similar) to indicate to the
requestor that another protocol has to be used for this query type. That
would also allow the DHCP server vendors to decide whether to allow UDP
based query types on TCP, if not ruled out by your draft.

Regards,

Marcus

---

From: Ted Lemon <[email-masked]>
Date: Tue, 16 Oct 2007 09:10:36 -0700

On Oct 16, 2007, at 8:37 AM, Marcus Goller wrote:
> Another option, in my opinion, would be to introduce an new status  
> code ("UnsupportedTransportLayer" or something similar) to indicate  
> to the requestor that another protocol has to be used for this  
> query type. That would also allow the DHCP server vendors to decide  
> whether to allow UDP based query types on TCP, if not ruled out by  
> your draft.

Generally speaking, doing it one way is better than doing it two  
ways.    I think using TCP for something like this makes a lot of  
sense - is there some reason why you are arguing for UDP?

---

From: "Marcus Goller" <[email-masked]>
Date: Tue, 16 Oct 2007 18:25:41 +0200

> sense - is there some reason why you are arguing for UDP?
I am not specifically arguing *for* UDP. I fully agree that using TCP makes
totally sense here. I just think that a query type should not implicitly
require a certain transport mechanism, it should be as independent as
possible. If it requires a certain underlying protocol, then the protocol
should allow to tell the requestor what is supported (or what not). This is
not an issue if the specification only defines one transport layer, but if
the requirements change, the protocol should be adopted accordingly. To me
it would not seem very clean to specifiy message type A,B and C to be
allowed only over UDP for example, D, E and F only over TCP, if it could be
avoided.
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Tue, 16 Oct 2007 09:46:57 -0700

On Oct 16, 2007, at 9:25 AM, Marcus Goller wrote:
> To me it would not seem very clean to specifiy message type A,B and  
> C to be allowed only over UDP for example, D, E and F only over  
> TCP, if it could be avoided.

But that's not really the choice you have.   The choice you have is,  
do you use TCP in cases where you need to reliably transfer bulk  
data, or do you implement an additional UDP-based reliability  
mechanism?   So in order to use UDP, you have to replicate  
functionality already present in TCP.   Which is why the objection to  
using UDP in this case.

So again, given that we would have to implement a whole new  
retransmission protocol in order to use UDP in this case, do you  
seriously think that we should support both UDP and TCP?

---

From: "Marcus Goller" <[email-masked]>
Date: Tue, 16 Oct 2007 18:57:40 +0200

> seriously think that we should support both UDP and TCP?
No, not if there would be the need to replicate the functionality of TCP.
Hence my suggestion to introduce a new status code, to tell the requestor
"Hey, we know that query type, but using it here is not supported. So go and
switch to another transport protocol". Just sending an "UnknowQueryType", if
it is indeed supported by the server, would just be misleading. The
behaviour of the server should just be consistent between UDP and TCP.
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Tue, 16 Oct 2007 10:44:42 -0700

On Oct 16, 2007, at 9:57 AM, Marcus Goller wrote:
> No, not if there would be the need to replicate the functionality  
> of TCP. Hence my suggestion to introduce a new status code, to tell  
> the requestor "Hey, we know that query type, but using it here is  
> not supported. So go and switch to another transport protocol".  
> Just sending an "UnknowQueryType", if it is indeed supported by the  
> server, would just be misleading. The behaviour of the server  
> should just be consistent between UDP and TCP.

Er, in a protocol sense, existing implementations already know what  
to do with UnknownQueryType; if you add a new status code, they need  
to know what to do with it as well.   Probably the behavior is the  
same: fail.   So presumably you mean that the implementor might find  
this confusing.   I guess I can see your point, but as long as the  
protocol is well-specified, it really shouldn't be a problem.

---

From: "Marcus Goller" <[email-masked]>
Date: Tue, 16 Oct 2007 20:32:50 +0200

> protocol is well-specified, it really shouldn't be a problem.
Ok, just wanted to get my point across and get some opinions on it. ;-)

Yes, new implementations would need to be able to to know what to do with
the new status code. But the new functionality needs some changes anyway,
existing implementations, not supporting these new query types, would not
see this new status code.
Is it required to make it work? No, I agree with you there.
Different status codes could only make it easier to take the appropriate
action on the requestor side and therefor minimize failed query attempts.
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Tue, 16 Oct 2007 11:41:04 -0700

On Oct 16, 2007, at 11:32 AM, Marcus Goller wrote:
> Different status codes could only make it easier to take the  
> appropriate action on the requestor side and therefor minimize  
> failed query attempts.

Apologies if I'm beating a dead horse, but if you just say "these  
queries are done by UDP and these are done by TCP," and there is no  
intersection, then there's no possibility of a query failure due to  
an unsupported transport.

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 16 Oct 2007 12:18:57 -0700

> "Hey, we know that query type, but using it here is not supported. So go and

Some protocols that extend from UDP->TCP like this create a status
code or flag that indicates the question should be made via TCP.  In
those cases they simply answer the question to the extent that can be
made to fit in the reply packet...something we can't (or shouldn't)
do in DHCPv6's case.

No one should think it is reasonable to attempt these queries over UDP
and fall back to TCP.  You try TCP first and last, no 'upgrade
mechanism' is efficient here.

So since any such status code is never going to be used assuming that
implementations comply with the spec...I'd suggest just treating a
UDP query with one of these types like it was garbage.  Drop and
(maybe) log.  No reply, no new status code.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Marcus Goller" <[email-masked]>
Date: Tue, 16 Oct 2007 22:02:00 +0200

> an unsupported transport.
If there is no intersection, then yes. But if I understand Marks answer
correctly, then it is not ruled out yet, that it would be possible to answer
UDP based query types over TCP (I future draft version can clarify that). I
could see that this might be useful if an existing TCP connection will be
used for all query types, once it is established.
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Marcus Goller" <[email-masked]>
Date: Tue, 16 Oct 2007 22:08:59 +0200

> (maybe) log.  No reply, no new status code.

This would require to definitely rule out that UDP based query types are
allowed over TCP, if I understand you correctly. Maybe it is just me, but
this is not 100% clear to me.
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Mark Stapp <[email-masked]>
Date: Tue, 16 Oct 2007 16:18:59 -0400

personally, I don't feel that the use of any of the existing queries 
over TCP has to be ruled out. it's the other orientation that could be 
... less than meaningful, so maybe that's what the new draft should forbid.

maybe I should add something like this to the next rev (depending on how 
the discussion plays out at the next meeting):

queries x, y, and z cannot be used effectively in the RFC5007 UDP 
protocol. requestors MUST NOT send queries x, y, or z to servers using 
RFC5007 leasequery.

Thanks,
Mark

Marcus Goller wrote:
> allowed over TCP, if I understand you correctly. Maybe it is just me, 
> but this is not 100% clear to me.
> 
> 
> ------------------------------------------------------------------------
>

---

From: Bud Millwood <[email-masked]>
Date: Wed, 17 Oct 2007 08:54:27 +0200

> protocol. requestors MUST NOT send queries x, y, or z to servers using

...and maybe something to the effect that responders MUST reply with an error?

I think allowing bulk transfers over UDP is a bad idea.

- Bud

-- 
Bud Millwood
Weird Solutions, Inc.
http://www.weird-solutions.com
tel: +46 8 758 3700
fax: +46 8 758 3687

---

From: Mark Stapp <[email-masked]>
Date: Wed, 17 Oct 2007 11:54:17 -0400

Hi, Bud,

> ...and maybe something to the effect that responders MUST reply with an error?

I think one of the questions that came up in Marcus's thread was, 
"should there be a new status code specifically about this?" that is, we 
have NotAllowed and we have UnknownQueryType, but maybe neither of those 
is sufficient to express: "the query is valid, but not permitted over 
the transport you're using."

-- Mark

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 17 Oct 2007 19:36:17 -0400

While this likely adds unnecessary complexity, as the "bulk" queries may
return 0, 1, or many clients, it is only the "many clients" response
that can't be allowed over UDP.

So, we could allow these queries over UDP and add a new "UseTCP" status
that a server would return in either ALL cases for these queries (if it
didn't want to even try supporting them over UDP for the 0 or 1 case) or
just for the "many clients" case (in this case the server would have to
do work to see whether it has more than 1 client that matches the
query).

The one query where this might be most useful is the QUERY_BY_REMOTE_ID
(5), which depending on how the relay agent constructs the remote-id,
could be unique for each and every client behind the relay. In other
cases, it may only indicate a circuit or device (such as a cable modem)
and there could be other devices behind it all sharing that remote-id.

I don't see this as being worth it; just defining which queries are
allowed ONLY over TCP should be sufficient. All queries should be
allowed over TCP (even the RFC 5007 ones).

---

On a separate but related note, one change that we should note in the
Bulk Leasequery Draft is that when the RFC 5007 queries are done over
TCP, there is no need to return the list of links on which clients are
located (and requiring the requestor to requery for each of the links).
Instead, a bulked response can be sent with the answers to the query.

It may be that over time that we deprecate the UDP based queries and
just use TCP.

- Bernie

-----Original Message-----
From: Mark Stapp (mjs) 
Sent: Wednesday, October 17, 2007 11:54 AM
To: Bud Millwood
Cc: [email-masked]
Subject: Re: [dhcwg] Bulk Leasequery for DHCPv6

Hi, Bud,

-- Mark