Subject: [core] draft-ietf-core-block-08 - clarification on client UDP port number

From: Anthony Baire <[email-masked]>
Date: Wed, 04 Apr 2012 18:06:15 +0200

Hi,

at the interop in Paris, we noticed one client implementation using a 
different UDP source port for each request in a blockwise transfer.

There is no mentions about UDP port numbers in draft-ietf-core-block-08.

While the client port number does not matter most of the time, there are 
possible problems in case of atomic Block1 transfers.

If two clients running on the same host are updating the same resource, 
then the server cannot distinguish for a certainty between the blocks of 
the two clients.

I would suggest adding one paragraph to Section 2.2:

    In the blockwise tranfer of a request payload (e.g., a PUT or POST)
    that the server is processing atomically, the client MUST originate
    every request from the same UDP source port. The reassembler MUST
    compare the UDP source port of the request when reassembling the
    blocks of an atomic operation. If atomic processing is not desired,
    there is no need to process the UDP source port.

Best Regards

--
Anthony Baire
IRISA / University of Rennes 1

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 4 Apr 2012 21:32:09 +0200

Now ticket #206.

Grüße, Carsten

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 23 Apr 2012 07:31:27 -0700

On Apr 4, 2012, at 9:06 , Anthony Baire wrote:

> we noticed one client implementation using a different UDP source port for each request 

just as a bit of information about this - long in the past, we saw SIP implementations that used new source ports frequently. Much of the time this works fine but unfortunately, these experienced lots of problems in some deployment scenarios and would not recommend writing your client this way. 

The issue is the that each new UDP flow is setting up new state in NATs, Firewalls, and various security systems and this often takes time. We found the first request on a new UDP flow was much more likely to be lost and typically took longer than  other UDP packets later in the same flow. In the case of carrier grade NATs, the number of UDP flows a given endpoint can have is often limited and given the UDP flows can only be "de-allocated" based on a timer (as the UDP flow has no FIN or RST), a client doing this may run out of flows it can use.