Subject: [core] draft-ietf-core-block-08 - Block Negotiation

From: Ashwin Sinha <[email-masked]>
Date: Wed, 11 Apr 2012 08:36:54 -0700

Hi,

With regard to the negotiation mechanism mentioned in the draft, how about
the case where initially both sides agree to say 64 bytes, then a couple of
exchanges later want to reduce/increase the size.

Also this might be an invalid question, the exchange is always a
client-server model, there cannot be any proxies in between? If so can they
modify this packet size, and how will this be handled.

Regards,
Ashwin

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 11 Apr 2012 17:54:06 +0200

> With regard to the negotiation mechanism mentioned in the draft, how about the case where initially both sides agree to say 64 bytes, then a couple of exchanges later want to reduce/increase the size. 

I'm not sure I understand the use case, but the client could e.g. switch to the next smaller block size by doubling the block number.  This is not explicitly allowed by the protocol right now (so a client might better be prepared for this to fail), but it is hard to implement the protocol in such a way that this wouldn't work.

> Also this might be an invalid question, the exchange is always a client-server model, there cannot be any proxies in between? If so can they modify this packet size, and how will this be handled.

An intermediary could map a single client request to multiple requests to the upstream server or v.v.; this is particularly easy with a caching proxy.  A very simple (stateless) intermediary would simply negotiate down the block size to a value comfortable to both its client and the origin server.  The protocol only describes the interaction between client and proxy and the interaction between proxy and origin server; it is the job of the proxy to make sure the semantics are maintained.

Grüße, Carsten

---

From: Ashwin Sinha <[email-masked]>
Date: Thu, 12 Apr 2012 20:17:58 +0530

> >>An intermediary could map a single client request to multiple requests
> to the upstream server or v.v.; this is particularly easy with a >>caching
> proxy.  A very simple (stateless) intermediary would simply negotiate down
> the block size to a value comfortable to both its >>client and the origin
> server.  The protocol only describes the interaction between client and
> proxy and the interaction between proxy >>and origin server; it is the job
> of the proxy to make sure the semantics are maintained.
>

   I wonder if it would be better to have a mechanism, which lets the
proxies know that they cannot go below a certain threshold. Like for
instance as a client I dont want my block size to be lesser than 64, and i
start initial negotiation with block size as 128, now I dont want any proxy
making this size less than 64.

  Regards
  Ashwin

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 12 Apr 2012 20:24:32 +0200

>    I wonder if it would be better to have a mechanism, which lets  
> the proxies know that they cannot go below a certain threshold. Like  
> for   instance as a client I dont want my block size to be lesser  
> than 64, and i start initial negotiation with block size as 128, now  
> I dont want any proxy making this size less than 64.

I haven't heard about a usecase where there is a lower bound that one  
endpoint would want to impose on another one.
If the proxy wants to go to 32 and there is a reason why that is a  
problem for the client, maybe that should use another proxy.
(Inversely, if you program a proxy, you shouldn't lower the block size  
unless there is a reason for that.)

But maybe I simply don't know enough about your usecase.

Gruesse, Carsten